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!
-
Show 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 -
Replying to @colmmacc
EtM is fine. If you’re worried about implementation bugs, you can combine (not cascade!) two stream ciphers. Ditto for the MAC. These can even run simultaneously on different cores. For very large messages, the synchronization overhead will be negligible anyway.
1 reply 0 retweets 0 likes
Combining also doubles (or more) any side-channel risks though. In GCM-SIV the GHASH or POLYVAL hash covers the plaintext, which works out to be more robust here. Never thought about it defending against implementation bugs before!
-
-
Replying to @colmmacc
But even if the tag doesn’t verify, the plaintext will be (shortly or permanently depending on the implementation) present in memory. Which may enable other kind of attacks. Which is why I still tend to prefer EtM.
1 reply 0 retweets 2 likes -
Replying to @jedisct1
+1 As it happens, I'm working on an interesting (I think) update for that which brings extra misuse-resistance beyond what either EtM or MtE can do on their own with minimal overhead.
0 replies 0 retweets 0 likes
End of conversation
New conversation -
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.