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

Hi Uri,

On 10/18/18, 12:29 PM, "Cfrg on behalf of Blumenthal, Uri - 0553 - MITLL" <cfrg-bounces@irtf.org on behalf of uri@ll.mit.edu> wrote:

>Smaller block sizes are easier to deal with in austere systems (memory, performance, etc.), whose concerns are only tactical.

I see two issues here.   First, what implementation advantages do small blocks have on rc5/rc6 on austere systems; is there an implementation study that quantifies those advantages?   Second, do we think that the implementers in those scenarios would understand and respect the block count limits?      We live in an era where people who use a 64-bit block cipher in an internet protocol without understanding the birthday bound can end up getting unwanted publicity like https://sweet32.info/SWEET32_CCS16.pdf.  We should strongly discourage the use of small block ciphers for general internet scenarios.  

As a research direction, small block ciphers used with beyond-the-birthday-bound modes of operation could be interesting, but that’s a tangent.

>
>Fire general use, 128-bit block seems a good balance.
>
>There are apps where larger block size is desired, e.g., for reasons you outlined.

Sure, but for an RFC, these should be documented.  

Best

David

>
>IMHO, the "Internet community" that is comprised of many diverse communities with different use cases and needs, would definitely benefit from adoption of this draft.
>
>Regards,
>Uri
>
>Sent from my iPhone
>
>> On Oct 18, 2018, at 10:33, 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
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg