Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

"Is there a footgun here that doesn't have an equivalent in GCM?"

Maaaybe- if you're doing the composition yourself.

You have to differentiate between the AAD and the ciphertext somehow, and you can screw that up (e.g. not putting the split location in the AD, sending it unauthenticated instead), while if you're using somebody else's GCM implementation they hopefully handle this correctly.

If somebody tells you to "do AEAD with this block cipher and this generic MAC", it's tempting to just ... find an implementation of the block cipher, find an implementation of the MAC, and play legos- neglecting subtleties like the split location, proper key derivation, etc.

It's far less tempting to implement GCM by composing implementations of CTR and GMAC because ... where would you even find an implementation of GMAC that's not part of a GCM implementation anyways?

Yes, the AAD encoding is a good point, and you're right (and so is everyone else that pointed this out, including the above commenter) --- there is an actual footgun here with how the AAD is encoded.

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

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.

> 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.

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.

Reply on news.ycombinator.com