[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfrg
Subject:    Re: [Cfrg] Changes in draft-irtf-cfrg-ocb-03
From:       David McGrew <mcgrew () cisco ! com>
Date:       2013-06-13 17:46:07
Message-ID: 1371145567.3892.731.camel () darkstar
[Download RAW message or body]

On Wed, 2013-06-12 at 15:56 -0700, Ted Krovetz wrote:
> I have just posted a revised Internet-Draft for OCB.
> 
> <https://datatracker.ietf.org/doc/draft-irtf-cfrg-ocb/>
> 
> A nice diff can be seen at
> 
> <http://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-ocb-03>
> 
> The most significant changes are:
> 
> 1. OCB uses an internal 128-bit nonce which is constructed from user-supplied nonce \
> N as 
> `Nonce = num2str(TAGLEN mod 128,7) || zeros(120-bitlen(N)) || 1 || N`  
> 
> This changes all generated tags except those that are 128 bits. The macro `num2str` \
> is also new and is now defined in the notation section. 
> 
> 2. The end of Appendix A adds test vectors for each named parameter set. All other \
> test vectors are unchanged because they had 128-bit tags. 
> 
> 3. The Security Considerations has a new paragraph on TAGLEN.
> 
> > Normally, a given key should be used to create ciphertexts with a
> > single tag length, TAGLEN, and an application should reject any
> > ciphertext that claims authenticity under the same key but a
> > different tag length.  While the ciphertext core and all of the bits
> > of the tag do depend on the tag length, this is done for added
> > robustness to misuse and should not suggest that receivers accept
> > ciphertexts employing variable tag lengths under a single key.

it is a sound approach to forbid the use of a single key with different
tag lengths, but the requirements language should be firmed up.  This
section should say something like "For each particular key, the value of
TAGLEN MUST be fixed."  

David

> 
> 
> 4. A new paragraph is added to the introduction making it clear that byte-oriented \
> implementations are okay. This is in response to an implementor who was worried \
> about his byte-oriented implementation being out of compliance with the spec. 
> > For reasons of generality, OCB is defined to operate on arbitrary
> > bit-strings.  But for reasons of simplicity and efficiency, most
> > implementations will assume that strings operated on are byte-strings
> > (ie, strings that are a multiple of 8 bits).  To promote
> > interoperability, implementations of OCB that communicate with
> > implementations of unknown capabilities should restrict all provided
> > values (nonces, tags, plaintexts, ciphertexts, and associated data)
> > to byte-strings.
> 
> Thank you everybody for your help in refining OCB. Phil and I really appreciate it.
> 
> -Ted
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg


[prev in list] [next in list] [prev in thread] [next in thread]