So to encrypt, and protect, our string, one scheme might be: AES(key, IV, "Ovaltine") -> encrypted_output HMAC(key, encrypted_output) -> MAC and then on the wire, we send: IV | encrypted_output | MAC
-
-
Another problem with length is that if you're using compression, and let attackers control any of the content on a page that a user sees, that can let the attackers figure out even small secrets. Look up the "CRIME" attacks. It's awesome, and scary.
Show this thread -
I said the other problem is timing. Obviously the timing of each message is public, but is that a big deal? It can be! For example, if you send a message for every use keystroke, it's trivial to figure out what they're typing through timing analysis. WOW.
Show this thread -
Another example is VOIP. If your call app only sends data when people are speaking, but not during the silences, that's still enough to guess about 70% of English-language speech. Just from the silences! Scary cool.
Show this thread -
These examples underling: even when you use encryption algorithms and schemes we've been perfecting for about 80 years, there's still some gaps you can walk into and break the security. Which is why this stuff is worth knowing!
Show this thread -
Anyway, that's the level I'm going to stick at for now, but we've covered a lot of ground. If you've finished this thread, thank you! But also you should now have some kind of better understanding of what's going on, and what to be wary of. Feel free to AMA.
Show this thread -
Oh the truth table for XOR is wrong. I guess it's more of a lies table. Should be: a | b | c 0 | 0 | 0 1 | 0 | 1 0 | 1 | 1 1 | 1 | 0
Show this thread
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.