3 ms·

This isn't an AEAD, it's just AE. AEAD implies the support for additional Authenticated Data (AD); this is just Encrypt-them-MAC, which is a good construction

This isn't an AEAD, it's just AE. AEAD implies the support for additional Authenticated Data (AD); this is just Encrypt-them-MAC, which is a good construction for authenticated encryption, but it's not AEAD (by definition). If you want an AEAD, I designed one based on ChaCha20 and BLAKE3 as a proof-of-concept a while ago: https://github.com/soatok/experimental-caead https://github.com/soatok/experimental-caead The important details: 1. You need to split a single key into 2 distinct keys (1 for [X]ChaCha, 1 for BLAKE3). 2. You need a canonical way to feed the ciphertext and AAD into BLAKE3. 3. You need to ensure your MACs are compared in constant-time. The GitHub repository I linked above does all this.

thatonelutenist 5y ago
The library that this was written for does in fact do all of the above, and I actually did look at your library for inspiration when I was doing background research. Big fan of your blog by the way. Though given the blog post is devoid of the context, and its apparently blown up a little, this is a valid wording concern and I'll edit the title.
tptacek 5y ago
I think this is an interesting conversation, but as normative feedback it seems pretty pedantic. The "AAD" in "AEAD" is message metadata; canonically, it's stuff like sequence numbers and metadata that appear in headers that need to be in cleartext to make transports work. Another example: Chapoly AAD is used to incorporate the transcript hash into every AEAD invocation of the WireGuard handshake. It seems like the obvious way you'd get AAD into generically-composed ChaCha+Blake is simply to include it in the Blake KMAC along with the ciphertext. In other words: the obvious way. Is there a footgun here that doesn't have an equivalent in GCM? I don't see it. The KDF point doesn't really have anything to do with AAD, right --- all you're saying here is that you need to KDF the ChaCha and Blake keys. I guess you're pointing out that GCM and Chapoly effectively do this for you in library implementations. Which, sure.
- some_furry 5y ago
  > The KDF point doesn't really have anything to do with AAD, right --- all you're saying here is that you need to KDF the ChaCha and Blake keys. I guess you're pointing out that GCM and Chapoly effectively do this for you in library implementations. Which, sure. The motivation for the KDF point is just to ensure we're not using the same key for two different algorithms. This condition almost never leads to any practical security risks (unless you're, I dunno, mixing AES-CBC with CBC-MAC?), but it makes people who care a lot about security proofs happier if we avoid it.
  - tptacek 5y ago
    Right, I certainly agree with you that if you're specifying a composition of ChaCha and Blake, you want to get these details right --- you need a KDF (most designs that use straight-up Chapoly already need one, because they're keyed from a DH) and, as you point out, a canonical encoding for the ciphertext and AAD. I think that's a good argument against just composing constructions "on the fly" casually, but to me, there are some kind of clear benefits to replacing the poly mac in Chapoly with a hash KMAC; it's worth going through this exercise (maybe just once) and then considering using it instead of a "standard" AEAD. By way of example: with the KDF and encoding --- which you can pull from x/crypto --- it seems like you could pretty easily make this proposed system fit Golang's AEAD interface.
- thatonelutenist 5y ago
  Its also feedback that doesn't really land, since the library I'm working on that this blog post was written in the context of actually does make extensive use of AAD, namely for verifying segment headers in files which must appear in plaintext for the protocol to work, but I'll allow it since this was posted to HN without context
  - vlmutolo 5y ago
    Haha well I did try (unsuccessfully) to give a little context in a comment when I posted it, pointing people to Asuran. But that was immediately buried by far more interesting comments. Next time it will be title text.

thatonelutenist 5y ago

The library that this was written for does in fact do all of the above, and I actually did look at your library for inspiration when I was doing background research. Big fan of your blog by the way. Though given the blog post is devoid of the context, and its apparently blown up a little, this is a valid wording concern and I'll edit the title.

tptacek 5y ago

I think this is an interesting conversation, but as normative feedback it seems pretty pedantic. The "AAD" in "AEAD" is message metadata; canonically, it's stuff like sequence numbers and metadata that appear in headers that need to be in cleartext to make transports work. Another example: Chapoly AAD is used to incorporate the transcript hash into every AEAD invocation of the WireGuard handshake. It seems like the obvious way you'd get AAD into generically-composed ChaCha+Blake is simply to include it in the Blake KMAC along with the ciphertext. In other words: the obvious way. Is there a footgun here that doesn't have an equivalent in GCM? I don't see it. The KDF point doesn't really have anything to do with AAD, right --- all you're saying here is that you need to KDF the ChaCha and Blake keys. I guess you're pointing out that GCM and Chapoly effectively do this for you in library implementations. Which, sure.

some_furry 5y ago
> The KDF point doesn't really have anything to do with AAD, right --- all you're saying here is that you need to KDF the ChaCha and Blake keys. I guess you're pointing out that GCM and Chapoly effectively do this for you in library implementations. Which, sure. The motivation for the KDF point is just to ensure we're not using the same key for two different algorithms. This condition almost never leads to any practical security risks (unless you're, I dunno, mixing AES-CBC with CBC-MAC?), but it makes people who care a lot about security proofs happier if we avoid it.
- tptacek 5y ago
  Right, I certainly agree with you that if you're specifying a composition of ChaCha and Blake, you want to get these details right --- you need a KDF (most designs that use straight-up Chapoly already need one, because they're keyed from a DH) and, as you point out, a canonical encoding for the ciphertext and AAD. I think that's a good argument against just composing constructions "on the fly" casually, but to me, there are some kind of clear benefits to replacing the poly mac in Chapoly with a hash KMAC; it's worth going through this exercise (maybe just once) and then considering using it instead of a "standard" AEAD. By way of example: with the KDF and encoding --- which you can pull from x/crypto --- it seems like you could pretty easily make this proposed system fit Golang's AEAD interface.
thatonelutenist 5y ago
Its also feedback that doesn't really land, since the library I'm working on that this blog post was written in the context of actually does make extensive use of AAD, namely for verifying segment headers in files which must appear in plaintext for the protocol to work, but I'll allow it since this was posted to HN without context
- vlmutolo 5y ago
  Haha well I did try (unsuccessfully) to give a little context in a comment when I posted it, pointing people to Asuran. But that was immediately buried by far more interesting comments. Next time it will be title text.