CTR is okay if: 1. You authenticate ciphertext. Sean does HMAC it. But as you point out, they have a weak CRC outside the HMAC. If that's checked before the HMAC, then someone can manipulate the protocol.
2. You do not repeat IVs. Sean's using a message ID concatenated a random nonce. This can be okay, but it depends how the ID is generated and how big the nonce is. For CBC, #1 still applies, but #2 is less severe. I'd probably just recommend using GCM for authenticated encryption. On Tue, Jun 11, 2013 at 2:38 PM, Mike Perry <mikepe...@torproject.org>wrote: > I was puzzled by this recommendation. CTR has several bad propeties that > can surprise you, and have bitten Tor as well. > > > The reason I ask is that this makes your IV-generation more critical > than, > > say, CBC, XTS, or other modes. If you have an IV collision, you'll leak > > some message bits. > > Additionally to this, CTR allows bit-level maleability of the cleartext: > a bit flipped in a CTR cipherstream translates into a bit flipped in > the cleartext. > > In fact, if there are regions of known cleartext (such as zeroes) the > adversary can do things like encode the originating IP in the cleartext > simply by XORing it into the cipherstream. > > This property can cause problems if you perform any operations before > checking the MAC (like evaluating a weak CRC to decide to forward the > message or not). > > CBC on the other hand causes a single ciphertext bitflip to scramble a > block of cleartext (16 or 32 bytes for 128bit vs 256bit) in an > unpredictable and key-dependent way. > > > -- > Mike Perry > > -- > Too many emails? Unsubscribe, change to digest, or change password by > emailing moderator at compa...@stanford.edu or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech >
-- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
