International Association
for Cryptologic Research

Key derivation functions (KDFs) are integral to many cryptographic protocols. Their functionality is to turn raw key material, such as a Diffie-Hellman secret, into a strong cryptographic key that is indistinguishable from random. This guarantee was formalized by Krawczyk together with the seminal introduction of HKDF (CRYPTO 2010), in a model where the KDF only takes a single key material input. Modern protocol designs, however, regularly need to combine multiple secrets, possibly even from different sources, with the guarantee that the derived key is secure as long as at least one of the inputs is good. This is particularly relevant in settings like hybrid key exchange for quantum-safe migration. Krawczyk's KDF formalism does not capture this goal, and there has been surprisingly little work on the security considerations for KDFs since then. In this work, we thus revisit the syntax and security model for KDFs to treat multiple, possibly correlated inputs. Our syntax is assertive: We do away with salts, which are needed in theory to extract from arbitrary sources in the standard model, but in practice, they are almost never used (or even available) and sometimes even misused, as we argue. We use our new model to analyze real-world multi-input KDFs---in Signal's X3DH protocol, ETSI's TS 103-744 standard, and MLS' combiner for pre-shared keys---as well as new constructions we introduce for specialized settings---e.g., a purely blockcipher-based one. We further discuss the importance of collision resistance for KDFs and finally apply our multi-input KDF model to show how hybrid KEM key exchange can be analyzed from a KDF perspective.

Two years ago, at RWC 2023 in Tokyo, we presented attacks on Mega—an end-to-end encrypted (E2EE) cloud storage provider with over 300 million users—and challenges on the path to designing a secure cloud storage protocol with end-to-end guarantees. Now, it is time for an update. In the past two years, analyses of multiple E2EE cloud storage providers revealed serious flaws in most systems, showing that the entire ecosystem is largely broken. At the same time, Google and Apple launched optional client-side encryption for Google Drive and iCloud, thereby making E2EE cloud storage available to their users (albeit with limited functionality). This is great news for privacy-minded users, but given the vulnerabilities that were discovered in most of the smaller providers, one may ask: how do we know if they are secure? Moreover, the vast majority of cloud storage providers still only use server-side encryption, which provides no protection against server compromise. Why is this the case? And what can we do about it? In this talk, we present the first cryptographic model for secure cloud storage in the malicious server threat model, formalizing E2EE cloud storage. Our model and security notions are motivated by our study of real-world E2EE cloud storage providers. We begin by briefly recapping our insights from analyzing MEGA and Nextcloud, identifying the main challenges that they struggled with. We then give a formal syntax for the core functionality of a cloud storage system, focusing on how we tailored the model to capture the real-world complexity of such systems. We continue by showing how we define the expected end-to-end security guarantees against a potentially compromised or malicious cloud server. Finally, we present the first provably secure E2EE cloud storage protocol. Along the way, we hope to inspire a discussion between academia and industry on the remaining challenges of bringing provably secure E2EE cloud storage to practice.

Key derivation functions (KDFs) are integral to many cryptographic protocols, turning raw (e.g., Diffie-Hellman) key material into strong cryptographic keys. Traditionally KDFs are designed and analyzed, for settings where they take a single key material input. Modern protocol designs, however, regularly need to combine multiple secrets (e.g., in hybrid key exchange for quantum-safe migration) with the guarantee that the derived key is secure as long as at least one of the inputs is good. Complex applications, especially in the setting where keys are user-managed, may even require threshold versions of KDFs. In this talk, we present lessons learned from analyzing such real-world proposals for multi-input KDFs. We first discuss combiner KDFs (aka key combiners), studying the designs in Signal's X3DH protocol, ETSI's TS 103-744 standard for hybrid key exchange, and MLS' combiner for pre-shared keys. Notably, the ETSI standard, widely recognized and recommended for use, for example by the German Federal Agency for IT Security, misuses the underlying HKDF salt input in a way that makes it insecure in its general form. We take the opportunity to revisit the syntax and security model for KDFs (mainly due to Krawczyk's HKDF paper, CRYPTO 2010) to give results on multiple-input KDFs. Taking an assertive stand on syntax, we do away with salts, which are needed in theory to extract from arbitrary sources in the standard model, but in practice, are almost never used (or even available) and sometimes even misused, as we saw. We then turn to the novel threshold primitive, which emerged as part of the multi-factor KDF (MFKDF) design (Nair and Song, USENIX 2023). We show how a naive implementation (such as the one proposed in MFKDF) leaves the scheme open to devastating cryptographic attacks and discuss ways forward.

End-to-end encryption (E2EE) allows data to be outsourced and stored on an untrusted server, such as in the cloud, without compromising its privacy. The need for stronger cryptographic guarantees for outsourced persistent data (such as encrypted files in cloud storage) has been highlighted by recent attacks on E2EE cloud storage providers, which all identify sharing as one of the main challenges. But even recently proposed E2EE cloud storage protocols which address this challenge suffer from another problem: when data is shared between a group of users, they all share access to the same, static, key material used for data encryption. This means that when the group membership changes, access control is only enforced by the server; security breaches or compelled disclosure would let even a removed member decrypt both current and future shared data. In this talk, we explore stronger security guarantees for groups of users and the data they share, and implement a practical system that delivers them. We propose to move away from the use of static keys for data encryption in the setting of file sharing. Taking inspiration from the related setting of continuous group key agreement (CGKA) [3] and the MLS standardization effort for group messaging, we introduce a new primitive, called group key progression, that enables a dynamic group of users to agree on a persistent sequence of keys. With our efficient instantiation of this primitive, called Grappa, group members can secure future and past data from former and future group members, respectively, while themselves retaining access to all of their data. We avoid expensive data re-encryption and ensure that all users in Grappa only need to keep a compact cryptographic state. Grappa uses CGKA as a core building block to transport key updates between users, hence finding a use-case for MLS beyond group messaging. In this talk, we want to share our take-aways from the journey of developing a file sharing system with strong security, from the novel theoretical building blocks, to challenges on the path to practice. On the theoretical side, we begin by showing that forward security (FS) and post-compromise security (PCS)—which are standard security notions for data in transit—are fundamentally more challenging to achieve for data at rest. Persistent data hence necessitates tailored methods to ensure strong end-to-end security. Instead of aiming for FS and PCS, we propose the new security notion of cryptographically-enforced interval access control (IAC), which gives similar guarantees in the common setting of persistent data applications where a group of users share access to the outsourced data, such as file sharing. On the practical side, we spent significant engineering effort to implement a file sharing system which utilizes Grappa to achieve both end-to-end security and IAC. In doing so, we uncovered several interesting limitations of the current cryptography ecosystem that we believe to be of interest to the RWC audience. These include the lack of support for low-level cryptographic primitives in the Web Crypto API, barriers to using MLS outside of the secure messaging context as a transport layer for Grappa, and challenges with developing new cryptographic applications for cross-platform usage.

Users increasingly store their data in the cloud, thereby benefiting from easy access, sharing, and redundancy. To additionally guarantee security of the outsourced data even against a server compromise, some service providers have started to offer end-to-end encrypted (E2EE) cloud storage. With this cryptographic protection, only legitimate owners can read or modify the data. However, recent attacks on the largest E2EE providers have highlighted the lack of solid foundations for this emerging type of service. In this paper, we address this shortcoming by initiating the formal study of E2EE cloud storage. We give a formal syntax to capture the core functionality of a cloud storage system, capturing the real-world complexity of such a system’s constituent interactive protocols. We then define game-based security notions for confidentiality and integrity of a cloud storage system against a fully malicious server. We treat both selective and fully adaptive client compromises. Our notions are informed by recent attacks on E2EE cloud storage providers. In particular we show that our syntax is rich enough to capture the core functionality of MEGA and that recent attacks on it arise as violations of our security notions. Finally, we present an E2EE cloud storage system that provides all core functionalities and that is both efficient and provably secure with respect to our selective security notions. Along the way, we discuss challenges on the path towards bringing the security of cloud storage up to par with other end-to-end primitives, such as secure messaging and TLS.

In Internet security protocols including TLS 1.3, KEMTLS, MLS and Noise, HMAC is being assumed to be a dual-PRF, meaning a PRF not only when keyed conventionally (through its first input), but also when "swapped" and keyed (unconventionally) through its second (message) input. We give the first in-depth analysis of the dual-PRF assumption on HMAC. For the swap case, we note that security does not hold in general, but completely characterize when it does; we show that HMAC is swap-PRF secure if and only if keys are restricted to sets satisfying a condition called feasibility, that we give, and that holds in applications. The sufficiency is shown by proof and the necessity by attacks. For the conventional PRF case, we fill a gap in the literature by proving PRF security of HMAC for keys of arbitrary length. Our proofs are in the standard model, make assumptions only on the compression function underlying the hash function, and give good bounds in the multi-user setting. The positive results are strengthened through achieving a new notion of variable key-length PRF security that guarantees security even if different users use keys of different lengths, as happens in practice.

As privacy-awareness rises, demand for end-to-end encrypted (E2EE) services is increasing. However, not all systems live up to their advertised security guarantees. MEGA—the largest provider of E2EE cloud storage with over 260 million users—failed to protect the confidentiality and integrity of their customers’ data, as our recent paper “MEGA: Malleable Encryption Goes Awry” showed. In this talk, we take a step back and discuss why it is surprisingly challenging to design a privacy-preserving cloud storage protocol that is secure even when the cloud provider is actively malicious. Recent academic effort focused on building file sharing systems which hide metadata. However, systems in practice still face much more fundamental challenges including key management, asynchronously coalescing updates stemming from collaboration on shared E2EE files, and cryptographic agility. We briefly discuss the approach of MEGA and how it was susceptible to a key recovery attack that allowed a malicious cloud provider to decrypt user files, among other vulnerabilities. Based on the attacks on MEGA, we suggest best practices for designing secure E2EE cloud storage systems. Unfortunately, it is infeasible for MEGA to completely redesign their system due to scale and backward compatibility. Even if a redesign was possible, the security they currently aim to provide still falls short of offering desirable properties like post-compromise security, forward security, and key rotation. With this in mind, we point out open questions for future work and advocate for a standardization process for a cloud storage design.

We introduce puncturable key wrapping (PKW), a new cryptographic primitive that supports fine-grained forward security properties in symmetric key hierarchies. We develop syntax and security definitions, along with provably secure constructions for PKW from simpler components (AEAD schemes and puncturable PRFs). We show how PKW can be applied in two distinct scenarios. First, we show how to use PKW to achieve forward security for TLS 1.3 0-RTT session resumption, even when the server's long-term key for generating session tickets gets compromised. This extends and corrects a recent work of Aviram, Gellert, and Jager (Journal of Cryptology, 2021). Second, we show how to use PKW to build a protected file storage system with file shredding, wherein a client can outsource encrypted files to a potentially malicious or corrupted cloud server whilst achieving strong forward-security guarantees, relying only on local key updates.