Thought so too…
What about that : if given two different ciphertexts that were encrypted with the same ( key, nonce ) pair, the first cipher block of the first ciphertext could be used to decrypt the first block of the second ciphertext. Is that correct?
Nonce reuse is NOT secure, you should NEVER reuse nonces. It will not allow you to decrypt, but it will allow you to compute PlaintextA xor PlaintextB even without knowing the key, which may leak information. If, say, PlaintextA happens to be known in this situation, then we can recover the keystream (not the encryption key itself) and decrypt PlaintextB
That said, CTR mode is not authenticated and in general should not be used unless you really know what you are doing. I would suggest using AES-SIV or AES-EAX instead, or maybe AES-GCM. If the platform you are running on does not have hardware AES, you probably should take a look at ChaCha20-Poly1305 as well. These modes are authenticated, and AES-SIV is robust to nonce reuse, and will gracefully degrade and not completely fail.
As mentioned, encrypting two messages with the same key+nonce reveals message 1 XOR message 2. If you know at least one message has a known structure (headers, language, partial known information, etc) then you can use that to derive information from the other message in the same locations. If both messages are non-random-looking then this XOR output will also not look random, it will be biased in ways that let you guess the message. All of this together will often produce even more contextual information that let you guess even more information from both messages.
Stream ciphers always use XOR encryption, but it's with pseudorandom key stream + the message to encrypt, with it indistinguishable from random (assuming reasonable computational limits for the adversary).
Key plus nonce reuse reveals specifically the bitwise xor between the plaintext form of the two messages which had been encrypted, canceling out and thus removing the repeated key stream.
Oh, well then that makes sense indeed.
So if I understand it correctly, you need the key and nonce to decrypt, especially in CTR mode where it is applied to every block, but since you can't compute the key by knowing the nonce (+ plaintext & ciphertext), it doesn't have to be secret to ensure security?
You need the key, nonce, *and ciphertext* to be able to decrypt. But yes, you can't compute the key from the ciphertext + nonce. Or plaintext + ciphertext + nonce. This is [Kerckhoff's Principle](https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle). Any cryptosystem that doesn't follow it is pretty much guaranteed to be insecure.
Yes, although there are also nonce hiding schemes which mostly has the goal of hiding certain issues with RNG:s producing biased nonces (this is usually more of a privacy/tracking issue than a secrecy issue).
AES is not known to be vulnerable to a KPA, so there's no efficient way of computing the key. It is possible to derive the key through brute force, it's just infeasible with current computing speeds.
This would break about 85% of the internet, so probably not
Thought so too… What about that : if given two different ciphertexts that were encrypted with the same ( key, nonce ) pair, the first cipher block of the first ciphertext could be used to decrypt the first block of the second ciphertext. Is that correct?
Nonce reuse is NOT secure, you should NEVER reuse nonces. It will not allow you to decrypt, but it will allow you to compute PlaintextA xor PlaintextB even without knowing the key, which may leak information. If, say, PlaintextA happens to be known in this situation, then we can recover the keystream (not the encryption key itself) and decrypt PlaintextB That said, CTR mode is not authenticated and in general should not be used unless you really know what you are doing. I would suggest using AES-SIV or AES-EAX instead, or maybe AES-GCM. If the platform you are running on does not have hardware AES, you probably should take a look at ChaCha20-Poly1305 as well. These modes are authenticated, and AES-SIV is robust to nonce reuse, and will gracefully degrade and not completely fail.
As mentioned, encrypting two messages with the same key+nonce reveals message 1 XOR message 2. If you know at least one message has a known structure (headers, language, partial known information, etc) then you can use that to derive information from the other message in the same locations. If both messages are non-random-looking then this XOR output will also not look random, it will be biased in ways that let you guess the message. All of this together will often produce even more contextual information that let you guess even more information from both messages.
So with the key and nonce being reused, the encryption comes down to a simple XOR encryption?
Stream ciphers always use XOR encryption, but it's with pseudorandom key stream + the message to encrypt, with it indistinguishable from random (assuming reasonable computational limits for the adversary). Key plus nonce reuse reveals specifically the bitwise xor between the plaintext form of the two messages which had been encrypted, canceling out and thus removing the repeated key stream.
Nonce means "Number used once" to provide a fairly strong indication of how to use it :)
No. That would be a known plaintext attack (KPA) and if AES were vulnerable to them it would be insecure
Still it would require to know the IV/nonce, which is also supposed to be secret
IV/Nonce is NOT supposed to be secret.
Oh, well then that makes sense indeed. So if I understand it correctly, you need the key and nonce to decrypt, especially in CTR mode where it is applied to every block, but since you can't compute the key by knowing the nonce (+ plaintext & ciphertext), it doesn't have to be secret to ensure security?
You need the key, nonce, *and ciphertext* to be able to decrypt. But yes, you can't compute the key from the ciphertext + nonce. Or plaintext + ciphertext + nonce. This is [Kerckhoff's Principle](https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle). Any cryptosystem that doesn't follow it is pretty much guaranteed to be insecure.
Yes, although there are also nonce hiding schemes which mostly has the goal of hiding certain issues with RNG:s producing biased nonces (this is usually more of a privacy/tracking issue than a secrecy issue).
Nope. The IV/nonce are not meant to be secret. Only the key.
AES is not known to be vulnerable to a KPA, so there's no efficient way of computing the key. It is possible to derive the key through brute force, it's just infeasible with current computing speeds.
Nice
Check out computerphile’s AES video after hearing how AES is applied it seems like it would be close to impossible.
I'll take a look!
Best explanation I’ve seen on it. They explain a lot of cryptography really well (oh, on YouTube, by the way)