

AEADs: getting better at symmetric cryptography - dochtman
https://www.imperialviolet.org/2015/05/16/aeads.html

======
tptacek
It took awhile for it to "click" with me why the "repeated ciphertext"
condition 'agl talks about in the first example is so bad. I mean, you can see
why it's undesirable, but it doesn't seem like a nightmare scenario.

It turns out to be a nightmare scenario in practice. You can use the behavior
as a building block in many protocols to get complete plaintext recovery from
controlled data ("chosen plaintext"):

[http://cryptopals.com/sets/2/challenges/12/](http://cryptopals.com/sets/2/challenges/12/)

This property is also the building block of Thai Duong and Juliano Rizzo's
"BEAST" attack, which targets CBC under a _predictable IV condition_ (note
again the distinction between nonces and IVs!).

Also, can't resist emphasizing: Rogaway not only predicted about a decade and
a half of blind-alley crypto in IETF protocols, but, when he did so, was
essentially run out of town on a rail by people calling him a "supposed
cryptographer". Rogaway is, of course, one of the best known academic
cryptographers in the world.

Standards Groups + Cryptography = Sadness.

~~~
Estragon
Thanks for the cryptopals challenges, I've been enjoying them.

------
knweiss
I wonder if there's a good explanation for non-experts that gives at least an
idea how an attacker would exploit the (key, nonce) pair reuse and why
everything fails so catastrophically?

~~~
agl
With both AES-GCM and ChaCha20-Poly1305, confidentiality is provided by XORing
the plaintext with a keystream generated by either AES or ChaCha20. If the
nonce is the same, then the same keystream is used.

Consider two plaintexts, p₁ and p₂, encrypted with the same (key, nonce) pair.
The ciphertexts will, in part, contain p₁⊕k and p₂⊕k, where k is the keystream
and ⊕ is XOR.

An attacker can XOR those ciphertexts together and get p₁⊕k⊕p₂⊕k = p₁⊕p₂⊕k⊕k =
p₁⊕p₂. If the attacker has any knowledge of p₁ or p₂ then the confidentiality
of the other falls as well.

The failure of the authenticator is more complex. Both AES-GCM and
ChaCha20-Poly1305 use polynomial authenticators and, in short, duplicating a
(key, nonce) pair allows the attacker to solve an equation and that's very
bad.

------
praseodym
According to RFC 5116 [1], there is 'associated data' (AD) as well as an
authentication tag (similar to a MAC). It seems like both can be used to
verify the authenticity of the ciphertext, but the article only mentions the
AD part. When do you use which?

The JDK8 documentation for the Cipher class has a paragraph on AEAD. This
mentions AAD; unencrypted "Additional Associated Data", but also calls the
same thing "Additional Authentication Data". Pretty confusing.

[1] [http://www.ietf.org/rfc/rfc5116.txt](http://www.ietf.org/rfc/rfc5116.txt)
[2]
[http://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher...](http://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html)

~~~
agl
Any authentication tag is a detail of the AEAD. As a practical matter, in
order to provide authentication, the AEAD must expand the plaintext and, in
some AEADs, that expansion comes in the form of a tag. But some AEADs just pad
the plaintext with zeros and use a variable-block cipher (i.e. AEZ), in which
case there's no tag as such.

Either way, it's an internal detail of the AEAD that someone using it doesn't
need to know about. The AEAD just needs to signal an error at decryption time
if the ciphertext has been manipulated.

The associated data(⁺) is just an input that needs to be equal at encryption
and decryption time. It can be empty, or it could be a counter, but it could
also be some other form of context, e.g. a string “payload for attachment #3
of message #234982374”. It's there to make sure that ciphertexts are
understood in the correct context, but it's not included in the ciphertext
itself.

The Java docs (and Java's crypto APIs are terrible in general I'm afraid) call
the AD _both_ “associated data” and “additional authentication data”. That's
just a mistake. At the very least they should be consistent within themselves
and I think they should pick “associated data” as the term to use.

(⁺) I called it “additional” data in my post, but since the RFC calls it
“associated” I changed it to that. It's the same thing.

------
finnn
The "BoringSSL" link in the second paragraph is broken, links back to the same
post.

~~~
agl
Opps, fixed. Thanks. It should have linked to
[https://www.imperialviolet.org/2014/06/20/boringssl.html](https://www.imperialviolet.org/2014/06/20/boringssl.html)

