Subject: [Cfrg] I-D Action: draft-irtf-cfrg-ocb-02.txt

From: [email-masked]
Date: Tue, 28 May 2013 09:22:26 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Crypto Forum Research Group Working Group of the IETF.

	Title           : The OCB Authenticated-Encryption Algorithm
	Author(s)       : Ted Krovetz
                          Phillip Rogaway
	Filename        : draft-irtf-cfrg-ocb-02.txt
	Pages           : 17
	Date            : 2013-05-28

Abstract:
   This document specifies OCB, a shared-key blockcipher-based
   encryption scheme that provides privacy and authenticity for
   plaintexts and authenticity for associated data.  This document is a
   product of the Crypto Forum Research Group (CFRG).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-ocb

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-irtf-cfrg-ocb-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-ocb-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 29 May 2013 10:47:15 +1000

> 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

---

From: Ted Krovetz <[email-masked]>
Date: Wed, 29 May 2013 07:28:29 -0700

James,

Thanks for looking over the document. I didn't mean for this announcement to get posted here, but a few small edits caused an auto-announcement. Sorry.

As for your concerns... AEAD_AES_128_OCB_TAGLEN128 and AEAD_AES_128_OCB_TAGLEN64 are different algorithms and a protocol will specify or negotiate one or the other, but not allow both simultaneously under the same key.

If for some reason a protocol did want to allow tags valid under either algorithm, then the two algorithms would need to operate under different keys. Just like if you wanted to accept messages with tags valid under either HMAC or CBC-MAC, you'd use different keys for each.

In other words, you are right. Shorter tags are simple truncations of longer tags. But, only a very poorly engineered system would be affected by this fact.

-Ted

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 29 May 2013 11:03:32 -0400

Ted,

Your explanation is perfectly satisfactory.

But I'd personally feel better if James M.'s suggestion was accepted -
i.e., if the tag length selection was explicitly encoded, perhaps the way
James proposed.

Tnx!
--
Regards,
Uri Blumenthal

On 5/29/13 10:28 , "Ted Krovetz" <[email-masked]> wrote:

>James,
>
>Thanks for looking over the document. I didn't mean for this announcement
>to get posted here, but a few small edits caused an auto-announcement.
>Sorry.
>
>As for your concerns... AEAD_AES_128_OCB_TAGLEN128 and
>AEAD_AES_128_OCB_TAGLEN64 are different algorithms and a protocol will
>specify or negotiate one or the other, but not allow both simultaneously
>under the same key.
>
>If for some reason a protocol did want to allow tags valid under either
>algorithm, then the two algorithms would need to operate under different
>keys. Just like if you wanted to accept messages with tags valid under
>either HMAC or CBC-MAC, you'd use different keys for each.
>
>In other words, you are right. Shorter tags are simple truncations of
>longer tags. But, only a very poorly engineered system would be affected
>by this fact.
>
>-Ted
>_______________________________________________
>Cfrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 May 2013 11:44:32 -0400

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 <
[email-masked]> wrote:

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

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Thu, 30 May 2013 19:21:37 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, May 29, 2013 11:45 AM
To: Manger, James H
Cc: [email-masked]
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

Is this ok?

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
[email-masked]<mailto:[email-masked]>
http://www.irtf.org/mailman/listinfo/cfrg

---

From: Rene Struik <[email-masked]>
Date: Thu, 30 May 2013 15:59:33 -0400

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:
> of the authentication tag in the live traffic, it almost certainly 
> won't pass authentication tag verification
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Richard Barnes
> *Sent:* Wednesday, May 29, 2013 11:45 AM
> *To:* Manger, James H
> *Cc:* [email-masked]
> *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.
>
> 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 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> 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.
>
> 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.
>
> 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
> [email-masked] <mailto:[email-masked]>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 30 May 2013 16:06:38 -0400

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 <[email-masked]>
Date:  Thursday, May 30, 2013 15:59
To:  "Igoe, Kevin M." <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
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
> 
>> 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:[email-masked] [mailto:[email-masked]] On Behalf Of
>> Richard Barnes
>> 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.
>> 
>>  
>> 
>> <[email-masked]> wrote:
>> 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.
>> 
>> 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
>> [email-masked]://www.irtf.org/mailman/listinfo/cfrg
> 
> 
> --

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Thu, 30 May 2013 21:04:58 +0000

Hi Rene,

From: Rene Struik <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 30, 2013 3:59 PM
To: "Igoe, Kevin M." <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

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:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, May 29, 2013 11:45 AM
To: Manger, James H
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Cfrg] Attacker changing tag length in OCB

James,

--Richard

Is this ok?

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>http://www.irtf.org/mailman/listinfo/cfrg

--
email: [email-masked]<mailto:[email-masked]> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 May 2013 17:34:48 -0400

To be clear, I was not saying that we shouldn't change OCB.  Just that this
is not a new problem for AEAD, nor one that will go away if we fix OCB.

On Thursday, May 30, 2013, Blumenthal, Uri - 0558 - MITLL wrote:

> 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
> From: Rene Struik <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>
> To: "Igoe, Kevin M." <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>
> Cc: "[email-masked] <javascript:_e({}, 'cvml', [email-masked]');>" <
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>>
> 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
>
> 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:[email-masked] [mailto:[email-masked]] *On Behalf Of
> *Richard Barnes
> *Subject:* Re: [Cfrg] Attacker changing tag length in OCB****
>
> ** **
>
> James,****
>
> ** **
>
> head, it seems that GCM, CCM, and SIV all have this property.****
>
> ** **
>
> their own.****
> ** **
> --Richard****
> ** **
> ** **
> [email-masked]> wrote:****
>
> http://www.irtf.org/mailman/listinfo/cfrg****<
>
> Cfrg mailing [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>http://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> --
> email: [email-masked] <javascript:_e({}, 'cvml', [email-masked]');> | Skype: rstruik

---

From: Rene Struik <[email-masked]>
Date: Thu, 30 May 2013 18:20:59 -0400

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 <[email-masked] <mailto:[email-masked]>>
> To: "Igoe, Kevin M." <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
>     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
>
>>     I agree with Richard.  The implicit assumption is that the length
>>     of the authentication tag has either been
>>
>>     parameter.  If you change the length
>>
>>     of the authentication tag in the live traffic, it almost
>>     certainly won’t pass authentication tag verification
>>
>>     *From:[email-masked] [mailto:[email-masked]] *On
>>     Behalf Of *Richard Barnes
>>     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
>>
>>     >       Title: The OCB Authenticated-Encryption Algorithm
>>     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?
>>
>>     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.
>>
>>     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
>     email:[email-masked]  | Skype: rstruik

---

From: Ted Krovetz <[email-masked]>
Date: Thu, 30 May 2013 17:15:47 -0700

> There's no reason not to introduce an extra bit of (maybe unnecessary?) protection

There are some costs.

- Redo test vectors. All the test vectors would have to be regenerated. This is not hard, but some confidence has been built up about the current vectors by several implementors, and the confidence building would need to start over.

- Change of algorithm. The OCB algorithm has been stable for some time, and OCB is already being used in some products. Any changes to the algorithm would be problematic for these early adopters.

Without these costs I would not hesitate to agree to the change, but with them I'm inclined to keep things as they are.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 30 May 2013 20:43:26 -0400

Test-vectors - that's nothing.

Algorithm stability - yes, that's a good argument. Under this condition I probably wouldn't change mine, so can't insist that you change yours. 

TNX!
--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <[email-masked]>
Lexington, MA  02420-9185       

Web:  http://www.ll.mit.edu/CST/

MIT LL Root CA: 

 <https://www.ll.mit.edu/labcertificateauthority.html>

DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Ted Krovetz [mailto:[email-masked]]
Sent: Thursday, May 30, 2013 08:15 PM
To: [email-masked] <[email-masked]>
Subject: Re: [Cfrg] Attacker changing tag length in OCB

There are some costs.

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 31 May 2013 15:48:18 +1000

David McGrew said
> 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_12…

Only a sender has to ensure nonces are unique. Even if a sender is completely diligent with nonces and only uses a fixed tag length with any given key, the problem of variable-length tags remains. What matters is whether a *recipient* accepts shorter tags than the sender uses.

It is good crypto hygiene only to use a given key with a single algorithm. It wasn't obvious to me whether different tag lengths for the same algorithm counted as a "single algorithm". Nor whether this hygiene was "nice" or "crucial" in this situation.

I agree with Peter Gutmann that it is a case of "when" not "if" the first misuse occurs. In many systems it is not easy to specify one algorithm at the same point where you provide the key.

Mixing the tag length into the ciphertext might even be a nice selling point for adopting OCB over other AEAD algorithms ;-)

At an absolute minimum, could a warning be added to draft-irtf-cfrg-ocb stating that any given key MUST only be used with one tag length. Probably in the 2nd-last paragraph of section 3 "OCB Global Parameters", and also in section 5 "Security Considerations".

Dan Brown said:
> 2) I'm uncertain whether modifying the message and substituting a shorter tag, per Rogaway and Wagner, [is an attack] because the authenticity is determined by the tag length, at least in CCM. In other words, calling this is an attack is conferring some level if authentication to the symmetric cipher.  That's a classic mistake. Any proposed fixes to this alleged problem had better not make this mistake.

It might not be an attack on an algorithm, but can we call it an attack on a system that implements a suite of algorithms?

--
James Manger