Authenticated Key Exchange and Signatures with Tight Security in the Standard Model

Abstract

We construct the first authenticated key exchange protocols that achieve tight security in the standard model. Previous works either relied on techniques that seem to inherently require a random oracle, or achieved only "Multi-Bit-Guess" security, which is not known to compose tightly, for instance, to build a secure channel.Our constructions are generic, based on digital signatures and key encapsulation mechanisms (KEMs). The main technical challenges we resolve is to determine suitable KEM security notions which on the one hand are strong enough to yield tight security, but at the same time weak enough to be efficiently instantiable in the standard model, based on standard techniques such as universal hash proof systems.Digital signature schemes with tight multi-user security in presence of adaptive corruptions are a central building block, which is used in all known constructions of tightly-secure AKE with full forward security. We identify a subtle gap in the security proof of the only previously known efficient standard model scheme by Bader et al. (TCC 2015). We develop a new variant, which yields the currently most efficient signature scheme that achieves this strong security notion without random oracles and based on standard hardness assumptions.

On the Concrete Security of TLS 1.3 PSK Mode

“…Numerous authenticated key exchange protocols [32,13,49,36,35] were recently proposed that can be proven (almost) tightly secure. However, these protocols were specifically designed to be tightly secure and none is standardized.…”

“…Accordingly, we scale the number of RO queries with the runtime, always setting #RO = t/2 10 . Number of pre-shared keys #N ∈ {2 25 , 2 35 }. The world's largest certificate authority Let's Encrypt reports ≈ 2 27.5 active certificates for fully-qualified domains.…”

“…We can see that the fixed preface of the transcript hash overlaps the fixed region of the HMAC hash that is fixed to either ipad or opad. Consequently, the legacy_session_id vector must begin within the fixed region (at byte 35). This is a variable-length vector preceded by a 1-byte length field, and its maximum length is 32 bytes [53,Section 4.1.2].…”