Hacker News new | past | comments | ask | show | jobs | submit login
Nonce-misuse resistant cryptography 101 (lvh.io)
9 points by lvh on May 21, 2016 | hide | past | favorite | 4 comments



>I can register using a name and e-mail address that has a lot of Z characters, and then I know that just XORing with Z will reveal most of the plaintext.

Wouldn't it reveal the stream of bytes the plaintext was XORed with, not the plaintext? Unless the article means indirectly, which would be strange writing.


I'm referring to the thing the attacker computes right before that sentence. The attacker has computed:

C_1 ^ C_2 = P_1 ^ P_2

The right hand side is known; it's the two ciphertexts. The right hand side is hence also known, but neither P1 nor P2 is known. Except, of course, if you have a plaintext that has a lot of Z's in it, because then I know one of P1/P2, and I can cancel out the Z's :) Is that what you mean by "indirectly"?


Another great description of cryptographic mechanics from lvh… Kind of do want to understand how authentication works with nonces too though. Any good sources for that?


Thanks! You've reminded me that I should also quote Joux' reuse attack against GCM, which is particularly disastrous: an attacker can create forgeries without knowing the master secret, making the result not IND-CCA2 secure.

It's something that's hidden in Crypto 101 right now, but not particularly obviously, and I should come up with a way to make that clearer. It differs a bit between the individual systems, but a lot of modern auth works on the same principle:

- we have secure MACs/ciphers that work on lots of data - we have fast authenticators, but they only work once (one-time MACs)

... so run the fast authenticator on the large pile of data and protect the fast authenticator with the secure construct (usually a cipher).

This is how Poly1305, for example, works: Poly1305 is a fast polynomial-based MAC that you run on the entire message, and then you protect its output with e.g. AES or ChaCha20. The nonce that Poly1305 takes actually works like a hidden CTR-like scheme: it's encrypted using AES, and the output is mixed with the fast (one-time-secure) MAC. An attacker doesn't know the encryption of the nonce under that AES key (that AES key is part of the authentication key), so they're unable to determine the original value of the Poly1305 polynomial.

The details of how e.g. GCM, secretbox... work are different, but it's the same idea.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: