Andy Isaacson <[email protected]> writes: >Yes, I'm thinking of the bit flip attack. Is a message still authentic >if it's been modified in transit? (Agreed that message integrity is a >more accurate term.) > >Ah, I see that you're compressing the plaintext before OTP, so many >simple bitflips result in a decompression error. However if the >attacker knows (part of) the plaintext or has a good guess, they can >still modify the message.
In practice, they'd have to know all or most of the plaintext, I think? Because under compression, the later parts of the (compressed) plaintext depend on earlier parts -- it's not like you can just jump in and modify bits in the middle of a compression stream. There's a long comment in the OneTime source code about a possible defense against this sort of thing. Essentially, put a random-length prefix of random data on the front of the plaintext before compressing. The user never sees the prefix; OneTime just adds it and subtracts it transperently, when encrypting and decrypting respectively. In the interests of code simplicity, I didn't implement that, as I didn't see a practical attack here. I still don't, but am definitely open to being corrected about that! It's just hard for me to see an attack that doesn't rely on having the plaintext already :-). Of course, then maybe the attacker can at least prove that that plaintext was what was tranismitted. In other words: If the attacker *does* have the full plaintext already, then they can be fairly certain that the transmission was of the that plaintext, because the attacker can compress the plaintext the same way OneTime does and then see if the length matches the crypttext length. The code comment I mentioned above is really about protecting from that length analysis, in fact. So that random prefix thing might still be worth implementing -- see the full discussion in the comment and let me know what you think. Please don't worry if I don't respond for several weeks. I'll be on vacation with no Internet, starting tonight. Best, -K -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at [email protected] or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
