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

List:       cfrg
Subject:    Re: [Cfrg] Attacker changing tag length in OCB
From:       Dan Brown <dbrown () certicom ! com>
Date:       2013-06-03 16:42:43
Message-ID: 810C31990B57ED40B2062BA10D43FBF518ABAC () XMB111CNC ! rim ! net
[Download RAW message or body]


More nuanced versions of my answers below (which doubtless overlap with 
others' answers).  By the way, I think this is a good question, and 
generalizes to beyond OCB.

> -----Original Message-----
> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of
> Manger, James H
> Sent: Tuesday, May 28, 2013 8:47 PM
> To: cfrg@ietf.org
> Subject: [Cfrg] Attacker changing tag length in OCB
>
> > 	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.

[DB]
Theorem 1 of
http://www.cs.ucdavis.edu/~rogaway/papers/ae.pdf
fixes the tag length.

I have not found a proof of security with variable tag lengths.

The most cautious approach would to be fix the tag length (per key).

Variable tag lengths per key may be useful, but it is crucial to state clearly 
the security characteristics of this mode.  If we cannot state them clearly, 
then users will not be able to use it right.  Perhaps countermeasures can 
added to that will probably avoid any mixups, but it is still much more 
important to state what the security characteristics are.

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

[DB]
On the one hand, informally speaking: Alice did actually send the message, so 
there is no attack, and this is property of OCB is ok.

On the other hand, somebody suggested to me, off-list, an interesting example. 
Suppose that Bob accept both tag lengths, and treats the messages differently 
according to tag length.  If the tag length is 64, then Bob makes the message 
public (or perhaps just protect the message less, e.g. store in the cloud). 
In other words, the tag length itself serves as the associated data, and 
serves as label, as in James' example below, with 64=Public and 
128=Top-secret.

I think it is reasonable in the example above for Bob to differentiate his 
response to a message based on tag length.  But I think that the set of 
allowed actions for longer tags should be larger, not smaller.  Better 
authentication means the message is more trustworthy.  The example above is 
wrong in that a shorter tag allowed more actions (i.e. publish the message). 
In other words, a system using OCB in this way would be reversing the meaning 
of authenticity.  I think the appeal of the example is the confusion between 
authenticity and privacy:  "Shorter tag?  Must be less private.  Okay to make 
public!".

If a system (a user of OCB) works in this way, then there is nothing an 
algorithm like OCB can do to secure it.  Therefore, it is much more important 
to state clearly what authenticity and other security services provided by the 
algorithm mean, to help prevent the system from going awry.  The definitions 
for OCB are probably clear enough for the fixed tag length, but not yet for 
variable tag length.

Personally, I am still quite confused about the conflict between privacy and 
authentication: to preserve privacy, Bob should restrict his actions on the 
received plaintext, but authenticity allows him to take more actions (which 
could leak information about the message).


["smime.p7s" (application/x-pkcs7-signature)]

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