Here's why! If we go back to my XOR example:https://twitter.com/colmmacc/status/1101572361365516288 …
-
Show 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 -
Replying to @jedisct1
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!
1 reply 0 retweets 1 like -
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
+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.
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.