3 ms·
AEAD was also a hipster scheme that literally nobody used. That's the whole point. In Twitter you even linked to Adam Langley's post where he suggests somethin
by shinigami 8y ago
AEAD was also a hipster scheme that literally nobody used. That's the whole point.
In Twitter you even linked to Adam Langley's post where he suggests something exactly like STREAM/CHAIN!
Which modern cryptosystems handle this problem? Tahoe-LAFS is the only one that comes to mind. Not being snarky here, I'm genuinely interested in knowing this.
- cyphar 8y agoModern TLS uses AEAD in the form of ChaCha20-Poly1305 as well as AES-GCM. I believe that the current standards in AEAD for ciphers are GCM-mode, EAX-mode and OCB-mode (CCM-mode is also used but only because it has no patents while OCB does -- CCM is more complicated and doesn't have some nice properties that OCB has).
- shinigami 8y agoYes, but that's an online protocol. The problem here is data at rest...
- cyphar 8y agoAll of the cipher suites I mentioned can be used with at-rest data (including ChaCha20-Poly1305, and AES-{GCM,EAX,OCB}), which means that there's nothing stopping PGP from adding support for them. But since you asked, the offline backup software restic[1] uses AEAD (though it's a mix of AES-256-CTR and Poly1305 rather than AES-GCM[2] -- but it's still an AEAD construction). I also recently started working on a paper-backup project, and used ChaCha20-Poly1305 over PGP because of the lack of AEAD (and also because it is vulnerable to surreptitious forwarding -- something that AEAD also solves[3]). There are distinctions between online and offline protocols (mainly related to PFS), but whether or not AEAD-capable cipher suites can be used is not one of them. [1]: https://restic.net/ https://restic.net/ [2]: https://blog.filippo.io/restic-cryptography/ https://blog.filippo.io/restic-cryptography/ [3]: https://www.usenix.org/legacy/publications/library/proceedings/usenix01/full_papers/davis/davis_html/index.html https://www.usenix.org/legacy/publications/library/proceedin...
- shinigami 8y agoAEAD is not enough. How do you decrypt/verify a 100 GB file with AEAD, without disclosing unauthenticated plaintext in a single pass? You need streaming AEAD like STREAM or CHAIN.
- cyphar 8y agoDoesn't OCB allow you to stream and verify in a single-pass (because the MAC is embedded in the 128-bit blocks of the underlying cipher blocks)?
- shinigami 8y agoI'm not sure I understand. In OCB (or any other AEAD) there is a single MAC for the entire ciphertext. You can't decrypt&verify large data in a single pass.
- cyphar 8y agoYou are completely right that for some constructions (such as ChaCha20-Poly1305, AES-CCM, and possible AES-GCM) there is only a single MAC for the entire ciphertext. However that is not true for other constructions. AES-OCB is a single-pass cipher that has a MAC for each block (this is actually the main selling feature of OCB). (AES-EAX also has a MAC for each block too, but is two-pass.) Also, STREAM/CHAIN are also AEAD, so your generalisation can't be always true.
- shinigami 8y agoI don't see it. From https://www.rfc-editor.org/rfc/rfc7253.txt https://www.rfc-editor.org/rfc/rfc7253.txt : Function name: OCB-ENCRYPT Input: K, string of KEYLEN bits // Key N, string of no more than 120 bits // Nonce A, string of any length // Associated data P, string of any length // Plaintext Output: C, string of length bitlen(P) + TAGLEN bits // Ciphertext Only a single tag, exactly like CCM and GCM. Am I missing something? It depends on what you call "AEAD", of course. For me it's something that generates a single MAC. STREAM/CHAIN can then be used with an underlying AEAD (GCM, CCM, OCB, SIV) to create a "streaming AEAD" that generates multiple chunks, each one of them with a MAC.