Deirdre Connolly¹ ²
Q: Identifiable abort?
A: Not this construction, there are options but they break other things
#realworldcrypto
Next up, 'XHMQV: Better Efficiency and Stronger Security for Signal's Initial Handshake based on HMQV', presented by Rune Fiedler
#realworldcrypto
XHMQV: Better Efficiency and Stronger Security for Signal’s Initial Handshake based on HMQV
The Signal protocol is the most widely deployed end-to-end-encrypted messaging protocol. Its initial handshake protocol X3DH allows parties to asynchronously derive a shared session key without the need to be online simultaneously, while providing implicit authentication, forward secrecy, and a form of offline deniability. The X3DH protocol has been extensively studied in the cryptographic literature and is acclaimed for its strong "maximum-exposure" security guarantees, hedging against compromises of users' long-term keys and medium-term keys but also the ephemeral randomness used in the handshake. This maximum-exposure security is achieved by deriving keys from the concatenation of 3–4 Diffie–Hellman (DH) secrets, each combining two long-term, medium-term, or ephemeral DH shares. Remarkably, X3DH's approach of concatenating plain DH combinations is sub-optimal, both in terms of maximum-exposure security and performance. Indeed, Krawczyk's well-known HMQV protocol (Crypto '05) is a high-performance, DH-based key exchange that provides strong security against long-term and ephemeral key compromise. One might hence wonder: why not base Signal's initial handshake on HMQV? In this work, we study this question and show that a carefully adapted variant of HMQV, which we call XHMQV, indeed enables stronger security and efficiency while matching the constraints of Signal's initial handshake. Most notably, HMQV does not work as a drop-in replacement for X3DH, as the latter's asynchronicity requires the protocol to handle cases where one party runs out of ephemeral keys (pre-uploaded to the Signal server). Our XHMQV design hence augments HMQV with medium-term keys analogous to those used in X3DH. We prove that XHMQV provides security in all 3–4 compromise scenarios where X3DH does and additionally in 1–2 further scenarios, strengthening the handshake's maximum-exposure guarantees while using more efficient group operations. We further confirm that our XHMQV design achieves deniability guarantees comparable to X3DH. Our security model is the first to capture Signal's long-term key reuse between DH key exchange and signatures, which may be of independent interest.
Sometimes you run out of prekeys and have to reuse one, this is 'reduced mode'
#realworldcrypto
More efficient, one less group exponentiation, stronger maximum exposure, but still doesn't help with exhaustion of prekeys
#realworldcrytpo
Signal protocol likes deniability, does that inhibit deniability? (No)
#realworldcrypto
Throw in a KEM alá PQXDH (ML-KEM prekeys) and you get hybrid-PQ security
#realworldcrypto
Might deploy it when taking advantage of other breaking changes such as PQ auth
#realworldcrypto
Next up, 'A Call to Action: Transitioning Signal's Private Group System to Quantum-Safe', presented by Rolfe Schmidt
#realworldcrypto
💯 (Signal is the only e2ee messenger that has strong protections on this stuff)
#realworldcrypto
The verifiable encryption, verified by the server, seems to be the most expensive/difficult part
#realworldcrypto
If clients can validate, we have new possibilities, and can simplify the system a lot
#realworldcrypto
Sigs instead of anon creds; re-randomizable to maintain privacy (as seen in Zcash!! <3)
#realworldcrypto
Exactly compatible with regular ML-DSA/Dilithium signatures
#realworldcrypto
Q: Are you sure about hybrid signatures?
A: No not necessarily, if we're confident in the pq option then we may not
#realworldcrypto
Next up, 'End-to-End Encrypted Collaborative Documents', presented by Christian Knabenhans and Zayd Maradni
#realworldcrypto
What do we need to serve journalists working on collaborative online documents?
#realworldcrypto
We need secure reconciliation mechanisms
#realworldcrypto
Apparently secure group messaging fulfills this!
#realworldcrypto
In prod, the network dominates performance
#realworldcrypto
The faster typer and receive, decrypt, and reconcile the slower typer's edits before they type their next character
👍
#realworldcrypto
Tested with the 20-page USENIX paper that this work is published in :D
#realworldcrypto
Q: Side channel leakage when sending every character on the wire?
A: Don't protect metadata, timing
#realworldcrypto
Q: Would this overwhelm Signal?
A: This is a small group of journalists, at scale there would be a more robust deployment
#realworldcrypto
Next up, 'Random-Access AEAD for Fast Lightweight Online Encryption', presented by Andres Fabrega and Gregory Rubin
#realworldcrypto
Sometimes AES-GCM doesn't work well when you are doing very very large plaintexts
#realworldcrypto
Need a streaming AEAD that is FIPSable and random-access
#realworldcrypto
Tweak nOAE to get randomized raAE notion
#realworldcrypto
There are no existing commitment notions [!]
#realworldcrypto
