Re: [Cfrg] Attacker changing tag length in OCB

[Rene Struik <[e-mail]>]

Hi David:

Agreed, in principle. Nevertheless, defining something along the lines 
k:=Hash(K, TagLength) has the benefit that if one does not heed the 
advice, one still does not run into trouble.

BTW - There may be use cases where having a "sliding scale" authenticity 
tag without having to change the key has advantages, e.g., in scenarios 
where one wishes to save bandwidth in non-adversarial environments (or 
when one nearly runs out of batteries and is more interested in 
squeezing as much out of the remaining communications, no matter the 
loss of authenticity). In those cases, having a built-in mechanism for 
deriving a tag length based key has some merit. Of course, one could 
achieve this functionality also via other means, such as, e.g., by 
partitioning the nonce space according to authenticity tag length, 
thereby using a tag-length based nonce, rather than a tag-length based 
derived key, and without the need to pick a hash function.

Best regards, Rene

On 5/30/2013 5:04 PM, David McGrew (mcgrew) wrote:
> Hi Rene,
>
> From: Rene Struik <[e-mail] <mailto:[e-mail]>>
> Date: Thursday, May 30, 2013 3:59 PM
> To: "Igoe, Kevin M." <[e-mail] <mailto:[e-mail]>>
> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] 
> <mailto:[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).
>
>
> Agreed.  The poor choice that is relevant here is the use of the same 
> OCB secret key with two different tag lengths.   If someone uses a 
> single key in both AEAD_AES_128_OCB_TAGLEN64 
> and AEAD_AES_128_OCB_TAGLEN128, then it is likely that they have also 
> not satisfied the nonce uniqueness requirements, so the tag truncation 
> and substitution attack seems like the least of their worries.   
> (Given two distinct nonce/associated data/plaintext tuples with 
> identical nonces, it is easy for the attacker to craft forgeries.)
>
> In general, it should be acceptable for an AE algorithm to require 
> that each of the keys that are used to instantiate it are independent 
> (as well as random or pseudorandom).
>
> David
>
>
>
>     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]
>>     <mailto:[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] <mailto:[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]
>


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]