by tptacek on 4/28/2025, 11:49:03 PM
by peterldowns on 4/28/2025, 11:41:25 PM
If you're interested in doing AEAD with the current best-practice algorithms in golang, you might get inspiration from my work-in-progress symcrypt package. I'm not a cryptographer and you shouldn't trust me when I say it works correctly — but it's basically just a small, correct, wrapper around the chacha20poly1305 code in the golang standard library. It has the slight advantage of using different types for the plaintext and the associated data (here called Owner, because I use it to store API keys owned by specific
If you squint at the example usage in the tests, it's basically the API that the blogpost describes.
https://github.com/peterldowns/symcrypt/blob/main/symcrypt_t...
As an aside, I'm always curious to understand why the encryption people say "never roll your own crypto" but then also ship confusing APIs without clear usage examples. For instance, check out the golang chacha20poly1305 docs:
by stavros on 4/28/2025, 11:59:58 PM
Can someone explain what use the AD is, if we have to decrypt the message to authenticate the AD? If I'm decrypting the message already just to authenticate it, why wouldn't I encrypt the AD as well?
by senderista on 4/29/2025, 1:04:20 AM
I don't understand the example. Presumably the server doesn't have the user-owned encryption key. So how can the server "detect that the user id has been tampered with" if it doesn't have the key necessary to authenticate the user id?
by twic on 4/28/2025, 11:49:08 PM
Internally, is AEAD just using the "usual" ciphers, digests, and PRNGs, just making sure to combine them in the right way? If so, are all AEAD "ciphers" the same, just with different sub-primitives plugged in?
by kazinator on 4/29/2025, 2:13:06 AM
The TL;DR of this seems to be: the plaintext metadata accompanying ciphertext ("associated data") is mixed into the ciphertext's encryption (essentially as an initial vector). Thereby, if the plain-text data is altered, the ciphertext cannot be correctly decrypted. The ciphertext is both a secret message, and a signature of the unencrypted data, so a separate HMAC is not required.
We can imagine, e.g. in the context of e-mail, if the DKIM header signature were combined a PGP-encrypted body as one operation. I'm ducking under the table now, though.
by andrekandre on 4/29/2025, 1:07:01 AM
i really appreciate how this article was written
just the right length and pacing to get me to the end and the point across
by dlenski on 4/29/2025, 11:49:40 PM
Look, it's a great article, but the perfect title was right there.
> What's my AEAD again, what's my AEAD again?
by halosghost on 4/28/2025, 11:11:21 PM
Another AD example: Ben Toews, in our Vault replacement secret storage system Pet Semetary, uses the AD on SQLite ciphertexts to bind them to a particular row (and/or a particular key path).
I wrote a local file encryption tool, around the same time Filippo was doing `age`, and used the AD on Chapoly to authenticate the chunk offset into the file. (The only thing interesting my tool did was that it could pull keys from AWS KMS).
So one use for AD is to authenticate headers; another is contextual binding.
If it helps (because 'stavros asked across the thread why bother having AD at all rather than just including it in the ciphertext), authenticated data can include data that doesn't even appear in the message, but rather is derived from the context at the time the message is encrypted and decrypted. A message only meant to be decrypted on a particular host (or whatever), for instance, could include the host in its AD, but never record that in the actual bits of the message.