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

David,

Thank you for taking the time to respond to my query about the OCB draft. I'm sorry to be so slow in answering your questions, but I was waiting to see if there were more comments.

> What is the rationale for larger-block OCB?

There are more block ciphers than those that are 128-bits and without modification OCB cannot be used with them. I don't want to speculate why someone would want to use a non-128-bit block cipher, but it seems a reasonable thing to have a good AEAD scheme available for them.

> 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.

Agreed. Whether the draft goes through CFRG or the independent stream, I'll try to improve it as you suggest.

> the security of an RC5/RC6 instantiation

The RC5/RC6 draft was mainly developed as an example for use with the OCB draft. Since there is so little cryptanalysis at nonstandard lengths, it may be more trouble than it's worth to promote the RC5/RC6 draft. If there's little or no interest in it, I'll drop the RC5/RC6 draft and find other block ciphers to be examples.

> the use of smaller block sizes should be restricted by strong guidance.

I did some of this, but will make it stronger.

-Ted

> On Oct 18, 2018, at 8:33 AM, David McGrew (mcgrew) <mcgrew@cisco.com> wrote:
> 
> 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" <cfrg-bounces@irtf.org on behalf of Kenny.Paterson@rhul.ac.uk> 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 <cfrg-bounces@irtf.org> on behalf of Ted Krovetz <ted@krovetz.net>
>> Date: Tuesday, 16 October 2018 at 15:03
>> To: "cfrg@ietf.org" <cfrg@ietf.org>
>> 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
>>   Cfrg@irtf.org
>>   https://www.irtf.org/mailman/listinfo/cfrg
>> 
>> 
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg