Re: [Cfrg] RFCs for wider-block RC6 and OCB

["David McGrew (mcgrew)" <[e-mail]>]

Hi Ted (and Kenny),

This is an interesting research direction, though it is not yet entirely clear how the internet community would benefit from its adoption.  I have some questions and comments that are focused on usage.  

What is the rationale for larger-block OCB?  Is it intended to improve security against cryptanalytic attacks in scenarios where other AEADs are currently used?   Or to allow each individual key to be used to encrypt a much larger volume of data?   The security considerations in ocb-wideblock says "a given key should be used to encrypt at most 2^(BLOCKLEN/2-16) blocks”, so actual guidance is consistent with the latter rationale.  What are the scenarios where AEAD needs to encrypt more than 2^52 bytes with a single key, and thus BLOCKLEN > 128 is needed?   In communication security, we change keys more often than that because we can and because keys can be compromised through side channels and system security issues.  I would guess that file/data encryption scenarios are the intended target, and if that’s right, it would be worth some discussion.  

The ocb-wideblock draft could call out the security benefits of larger block sizes more strongly, and could change the security considerations in a way that moves users away from the birthday bound.  

I’m confident in the security analysis behind the ocb-wideblock draft, but the security of an RC5/RC6 instantiation of that mode depends crucially on the ability of those ciphers to look like a PRP as their block size gets larger.  The security considerations of the rc5/rc6 draft does touch on this, saying that "Each doubling of w should increase the number of rounds by four”, but it does not cite any cryptanalysis of those ciphers with larger block sizes, other than the work of the cipher design team, unless I’m missing something.  While that design team has a sterling reputation, independent analysis is important.  The RC6 cryptanalysis literature from the time of the AES competition was focused on a 128-bit block size.  The draft ought to cite a more detailed justification for the security of wider-block rc5/rc6.  

I am totally missing the rationale for using *smaller* block sizes, and I think they should be removed from the draft, unless there is some compelling use case that they are targeting.   In that event, the use of smaller block sizes should be restricted by strong guidance.   

best

David


On 10/17/18, 6:07 PM, "Cfrg on behalf of Paterson, Kenny" <[e-mail] on behalf of [e-mail]> wrote:

>Dear Ted,
>
>Thanks for bringing this ID to CFRG's attention.
>
>The chairs would like to encourage people to continue to express their views on whether CFRG should adopt this ID as a CFRG work item or not. People can do that on-list or privately to the chairs if they prefer.
>
>Thanks,
>
>Kenny (for the chairs)
>
>
>-----Original Message-----
>From: Cfrg <[e-mail]> on behalf of Ted Krovetz <[e-mail]>
>Date: Tuesday, 16 October 2018 at 15:03
>To: "[e-mail]" <[e-mail]>
>Subject: [Cfrg] RFCs for wider-block RC6 and OCB
>
>    Hello,
>    
>    About six months ago I put together an Internet-Draft that specified how to use the authenticated-encryption algorithm OCB and a block cipher without 128-bit blocks. This was in response to a few researchers and developers who had expressed interest in such a thing. As an exemplar I wrote RC6 (and RC5) code and an Internet-Draft for block lengths other than originally intended.
>    
>    https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/
>    https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/
>    
>    My question for CFRG is whether I should pursue these RFCs through the Independent submission channel, or whether there is interest within CFRG to review and/or sponsor the drafts.
>    
>    Thank you,
>    Ted Krovetz
>    _______________________________________________
>    Cfrg mailing list
>    [e-mail]
>    https://www.irtf.org/mailman/listinfo/cfrg
>    
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/cfrg