Bloom Filter Encryption and Applications to Efficient Forward-Secret 0-RTT Key Exchange

Abstract

Forward secrecy is considered an essential design goal of modern key establishment (KE) protocols, such as TLS 1.3, for example. Furthermore, efficiency considerations such as zero round-trip time (0-RTT), where a client is able to send cryptographically protected payload data along with the very first KE message, are motivated by the practical demand for secure low-latency communication. For a long time, it was unclear whether protocols that simultaneously achieve 0-RTT and full forward secrecy exist. Only recently, the first forward-secret 0-RTT protocol was described by Günther et al. (Eurocrypt, 2017). It is based on puncturable encryption. Forward secrecy is achieved by “puncturing” the secret key after each decryption operation, such that a given ciphertext can only be decrypted once (cf. also Green and Miers, S&P 2015). Unfortunately, their scheme is completely impractical, since one puncturing operation takes between 30 s and several minutes for reasonable security and deployment parameters, such that this solution is only a first feasibility result, but not efficient enough to be deployed in practice. In this paper, we introduce a new primitive that we term Bloom filter encryption (BFE), which is derived from the probabilistic Bloom filter data structure. We describe different constructions of BFE schemes and show how these yield new puncturable encryption mechanisms with extremely efficient puncturing. Most importantly, a puncturing operation only involves a small number of very efficient computations, plus the deletion of certain parts of the secret key, which outperforms previous constructions by orders of magnitude. This gives rise to the first forward-secret 0-RTT protocols that are efficient enough to be deployed in practice. We believe that BFE will find applications beyond forward-secret 0-RTT protocols.

A Cryptographic Analysis of the TLS 1.3 Handshake Protocol

“…8] acknowledges that "TLS does not provide inherent replay protections for 0-RTT data," and at the same time urges implementations to at least implement a certain basic level of anti-replay protection (like single-use session tickets, ClientHello recording, or freshness checks). The 0-RTT modes of Google's QUIC protocol and TLS 1.3 spawned a series of academic treatments of 0-RTT key exchange [52,62,78] and new designs of forward-secure encryption [30,59] to achieve forward-secret and non-replayable 0-RTT key exchange [46,57] and TLS session resumption [6]. Also, from a cryptographic perspective, the Diffie-Hellman-based 0-RTT mode variant offered a higher level of (forward) security as it did not require the client to keep secret state for resumption and hence only server compromises would affect the secrecy of 0-RTT communication [53,74].…”