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 -
So really you need MAC-then-encrypt-then-also-MAC! I call this scheme Combined Online Linear Message MAC And Corruption Check (it's ok to shorten that to COLMMACC).
2 replies 4 retweets 37 likesShow this thread
But seriously; if you used this cipher for a large volume data store (we don't!) fixing this would be a *major* pain. You'd have to decrypt and re-encrypt everything. If it crossed control boundaries, you'd have to tell users to keep a copy of the broken cipher implementation.
-
-
It's like the worst kind of applied crypto pain. Changing network crypto is easy in comparison! TLDR: version *everything* always, and include a plaintext checksums if you have to worry about long-term durability minutia like this. /out
2 replies 1 retweet 8 likesShow this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.