Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

[Samuel Neves]

On 12/01/2016 02:03, Watson Ladd wrote:
> However, free-start collisions have been found, as have ways to modify
> constants in the SHA-1 IV to get collisions.

To be clear, the research into maliciously altering SHA-1 to make collisions 
easier changed the K_i constants added
during the rounds, not the IV.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Data volume limits

[Samuel Neves]

On 01/01/2016 06:35 AM, Aaron Zauner wrote:
> This might be a good time to point again to my existing AES-OCB
> draft that hasn't really seen a lot of discussion nor love lately.
> It expired but I've recently updated the draft (not yet uploaded
> to IETF as I'm waiting for implementer feedback from two particular
> sources). The update has something to do with how GCM is implemented
> in some stacks though, see:
> https://github.com/azet/draft-zauner-tls-aes-ocb/commit/26c2fff7808fc88bf47e5d097f2ff5ca23201029

OCB is, if anything, worse than GCM when it comes to data volume limits. It has 
the same confidentiality bounds as GCM
(slightly worse, in fact), but once you hit a collision you also lose 
authenticity and enable simple forgeries [1].

The real issue here is the block size of AES, not the security bounds of 
particular modes. Those are by and large all
limited by the birthday bound. You could go with more exotic beyond-birthday 
modes, but there don't seem to be any being
proposed for TLS. The simple solution to the birthday blues is, of course, to 
use a larger block.

[1] 
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/General_Comments/papers/Ferguson.pdf

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Data volume limits

[Samuel Neves]

Quoting Aaron Zauner :


On the other hand, after 2^60 OCB messages of 2^16 blocks (and thus 2^76
total blocks), a block collision is almost guaranteed to have happened,
enabling the aforementioned forgeries.


Sure. Would you see any way to improve this situation in the draft,
i.e. give implementation recommendations or similar?



I think the FAQ you quoted before (itself quoting RFC 7253) suggesting  
the limitation of blocks processed to 2^48 is reasonable. Depending on  
the consensus here on what an acceptable success probability for an  
attacker is, you may want to bring that down to 2^32, as is being  
suggested for GCM.


P.S.: Apologies. I had interpreted your diversion into OCB as  
suggesting it as an alternative to GCM to address the data volume  
limitation in question. On a second read, that turned out not to be  
the case, and you were only asking for help.



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls