[liberationtech] New Anonymity Network for Short Messages

[Steve Weis]

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 <mikeperry at 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 companys at stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130611/7d0d3dc6/attachment.html>