Re: [Cfrg] Attacker changing tag length in OCB

["Blumenthal, Uri - 0558 - MITLL" <[e-mail]>]

Kevin,

You agree with Richard ­ and I agree with Rene and James. There's no reason
not to introduce an extra bit of (maybe unnecessary?) protection, as
justification "nobody could/would get this wrong" has failed many people
many times.
--
Regards,
Uri Blumenthal

From:  Rene Struik <[e-mail]>
Date:  Thursday, May 30, 2013 15:59
To:  "Igoe, Kevin M." <[e-mail]>
Cc:  "[e-mail]" <[e-mail]>
Subject:  Re: [Cfrg] Attacker changing tag length in OCB

> Dear colleagues:
> 
> The observation that some AEADs have the property that one can truncate the
> authentication tag without affecting AEAD unsecuring operations was brought up
> by Rogaway and Wagner in their 2003 "Critique on CCM" paper (Section 3.4). It
> is therefore kind of interesting to see that the same observation applies to
> the OCB mode.
> 
> Whether or not it is good to build-in protection against poor policy choices
> and management thereof is a matter of taste. History suggests that lots of
> security vulnerabilities arise precisely because of these poor choices (or
> lack of knowledge of impact of policy on security services offered). One could
> shield against poor choices in various ways, e.g., by using as key k:=Hash(K,
> TagLength).
> 
> Best regards, Rene
> 
> Ref: CCM Mode Critique (Rogaway, Wagner,  IACR ePrint 2003-070)
> http://eprint.iacr.org/2003/070
> 
> On 5/30/2013 3:21 PM, Igoe, Kevin M. wrote:
>> I agree with Richard.  The implicit assumption is that the length of the
>> authentication tag has either been
>> agreed upon during the handshake or was a previously agreed upon parameter.
>> If you change the length
>> of the authentication tag in the live traffic, it almost certainly won¹t pass
>> authentication tag verification
>> by the intended recipient.  Offhand, I don¹t see a security problem here.
>>  
>>  
>> 
>> From:[e-mail] [mailto:[e-mail]] On Behalf Of
>> Richard Barnes
>> Sent: Wednesday, May 29, 2013 11:45 AM
>> To: Manger, James H
>> Cc: [e-mail]
>> Subject: Re: [Cfrg] Attacker changing tag length in OCB
>>  
>> 
>> James,
>> 
>>  
>> 
>> Don't most current AEAD modes have this property?  Namely, that there's no
>> protection on the length of the authentication tag.  Off the top of my head,
>> it seems that GCM, CCM, and SIV all have this property.
>> 
>>  
>> 
>> So while it might be nice for OCB to fix this issue, implementations
>> processing AEAD messages will still have to enforce minimum tag lengths on
>> their own.
>> 
>>  
>> 
>> --Richard
>> 
>>  
>> 
>>  
>> 
>> On Tue, May 28, 2013 at 8:47 PM, Manger, James H
>> <[e-mail]> wrote:
>>> >       Title           : The OCB Authenticated-Encryption Algorithm
>>> >       Filename        : draft-irtf-cfrg-ocb-02.txt
>>> > http://tools.ietf.org/html/draft-irtf-cfrg-ocb-02
>> 
>> OCB with tag lengths of 64, 96, and 128 bits are defined. 64-bit and 96-bit
>> tags are simply truncated 128-bit tags. The tag length is not mixed into the
>> ciphertext. It never affects any input to an AES operation.
>> 
>> Consequently, given a valid output from the AEAD_AES_128_OCB_TAGLEN128
>> algorithm it is trivial to produce a valid output from the
>> AEAD_AES_128_OCB_TAGLEN64 algorithm -- just drop the last 8 bytes.
>> 
>> Is this ok?
>> 
>> Another consequence is that an attacker wanting to change the additional data
>> (eg from saying "TOP SECRET" to "PUBLIC") while keeping the same plaintext
>> only has to defeat the shortest tag a recipient accepts, regardless of the
>> tag applied by the originator.
>> 
>> Is this ok? It doesn¹t feel ok.
>> 
>> Of course if a recipient accepts 64-bit tags an attacker can forge messages
>> with a probability of 2^-64. However, that doesn¹t seem to be exactly the
>> same as forging a message with the same plaintext as a message originally
>> authenticated with a 128-bit tag.
>> 
>> Would OCB be better if the algorithms with different tag lengths couldn¹t
>> affect each other? Perhaps restricting the nonce to <126 bits (instead of
>> <128 bits) and encoding the tag length in 2 bits.
>> 
>> --
>> James Manger
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
>>  
>> 
>>  
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]://www.irtf.org/mailman/listinfo/cfrg
> 
> 
> -- 
> email: [e-mail] | Skype: rstruik
> cell: [phone] | US: [phone]