The counter should be able go to 2^64, which is big enough to encrypt extremely large volumes of data. The bug is that it cycles at 2^32, far far lower.https://twitter.com/FiloSottile/status/1108569374343000064 …
-
Show this thread
-
The effect is that after generating 256GiB of cipher stream, the cipher will generate incorrect output and then cycle back and generate the same data it began with. Now to be clear, Salsa20 was not designed to be used for more than 4Kib at a time,
@hashbreaker very clearly warns!2 replies 0 retweets 1 likeShow this thread -
But the implementations don't stop you from doing it. They aren't misuse-resistant. This is very very bad. If you encrypt two strings using the same cipher string, it's generally trivial to decrypt them.
1 reply 0 retweets 2 likesShow this thread -
Colm MacCárthaigh Retweeted Colm MacCárthaigh
Here's why! If we go back to my XOR example:https://twitter.com/colmmacc/status/1101572361365516288 …
Colm MacCárthaigh added,
1 reply 0 retweets 1 likeShow this thread -
So in my example 3 was the plaintext, and 7 was the key. 3 ^ 7 = 4, so that's the encrypted text. Let's say we encrypted 5 too. 5 ^ 7 = 2. Well it turns out that XORing the encrypted text is just like XORign the plaintext. 3 ^ 5 = 6, and 4 ^ 2 = 6.
1 reply 1 retweet 2 likesShow this thread -
So re-using the same stream reveals the "difference" between the plain-texts. There's enough information in there to make guesses at what the plaintext is. O.k. so the bug is bad, and has to be fixed. Real world things could hit this: e.g. people might be encrypting a snapshot.
2 replies 0 retweets 3 likesShow this thread -
But here's what interesting: the fix also breaks anything that's already encrypted! if you stored a > 256GiB encrypted image using Salsa20 ... it will now partially decrypt to garbage.
1 reply 0 retweets 3 likesShow this thread -
The normal defense against this in cryptography is the MAC. A MAC is basically a keyed checksum of the data; if the data ever changes, even by one bit, the MAC should fail to validate. But in this case, an encrypt-then-MAC style MAC will be absolutely valid!
1 reply 0 retweets 1 likeShow this thread -
To detect this kind of corruption: you'd need to have a MAC of the plaintext. MAC-then-encrypt is usually considered a bad practice, because it leaves the cryptography open to side-channel experimentation by attackers, but in this case you absolutely need it!
2 replies 0 retweets 2 likesShow this thread -
Replying to @colmmacc
You could use SIV mode, which does indeed (safely) MAC the plaintext. But I guess if you are decrypting >256GB then you are almost certainly releasing unverified plaintext.
1 reply 0 retweets 0 likes
Good point! Two full passes of the plaintext on the encryption phase would be very expensive at that scale too.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.