Not my blog. The author works on a backup/archival tool called “Asuran”, which I assume motivates a lot of the research into AEAD.
I had never heard of the “partitioning oracle” attack, which is a really interesting way to exploit Poly1305 tags under certain conditions. I never would have assumed that it’s practical to generate multiple ciphertexts that all authenticate under the same Poly1305 tag. That property leads to some interesting attacks.
I was this close to guessing “because you don’t have to memorize a phone number-length sequence of digits to use them”
Something makes me want to study cryptography just to name a cipher Poly01189998819991197253.
Interesting. I choose XChaCha20-Poly1305 for a very different set of reasons:
One of the comments refers to a library that implements the XChacha20+Blake3 construction but I couldn’t find a link to it.
The partitioning oracle attack looks interesting. The idea is that you create a cyphertext that generates the correct integrity MAC for many keys and then submit it to something that tries to decrypt it with the correct key and reports whether it worked. Practically, this is a concern if you expose an API that allows an attacker to submit large numbers of cyphertexts for you to decrypt and provides a signal back about whether they succeeded.
From what I have read in a quick skim on the subject, a partitioning oracle attack on Poly1305 gives a factor of 10 speedup for an attacker performing a brute force attack, which equates to losing a little over 3 bits of key length, which sounds like the kind of attack that if fun in theory but makes absolutely no difference in practice. I can’t imagine any scenario where a factor of 10 is the difference between a practical and impractical attack on a cryptosystem, unless it composes with other weaknesses.
So the trade here is implementing your own AEAD construction versus being vulnerable to an attack that marginally reduces work factor for the attacker and relies on a exposing an API that works as an oracle.