4 ms·
> 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
by 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 agoRight, 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.