Subject: Re: [Cfrg] draft-mcgrew-auth-enc-03.txt

From: David McGrew <[email-masked]>
Date: Wed, 5 Sep 2007 14:27:33 -0700

Hi Dan,

sorry for the delay in replying, I've been out of the office and away  
from mail.  More inline:

On Aug 10, 2007, at 2:31 PM, Dan Harkins wrote:

>
>   Hi David,
>
>   I have a couple questions about draft-mcgrew-auth-enc-03.txt.
>
>   Section 4 states requirements for AEAD algorithms with respect to  
> the
> lengths of various inputs-- maximum amount of plaintext is P_MAX,  
> maximum
> amount of additional authenticated data is A_MAX, etc. Are these to be
> treated as logical limits imposed by the particular mode (for instance
> fixing q to 3 for CCM imposes a P_MAX limit that would not be so low
> if q was greater) or are they to be treated as "safe" limits?
>
>   If the latter then what is the guidance that this limit should  
> provide?
> Is it a soft limit under which one should be fine but the proven  
> security
> guarentee falls off after you reach the limit or is it a hard limit  
> that
> the cipher becomes too unsafe to use after you reach the limit?

The A_MAX and P_MAX are hard limits.  They don't really set a  
complete security policy, since they define the maximum length of  
individual inputs, and they don't take the aggregate input length  
into account.

Typical advice on using block cipher modes says to not use a single  
key to process more than 2^(w/2) input blocks, where there are w bits  
in the block cipher inputs and outputs.  This is sound advice, though  
conservative users might want to choose a lower number like 2^(3w/ 
8).   (That's what we did in Secure RTP, FWIW.)

> How should
> another AEAD algorithm that wishes to have a number assigned out of  
> the
> registry define these maximums? SIV's counter is 128 bits, if it was
> incremented mod 2^128 P_MAX logically would be 2^128 but SIV's  
> security
> guarantee falls off after 2^64 so should P_MAX be less?
>

I would think 2^64 octets would be a reasonable value for P_MAX.

>   On a related note, for CCM the I-D defines P_MAX as 2^24-1 octets  
> and
> A_MAX as 2^64-1 octets. Theorem 1 in the Jonsson paper referenced  
> as [J02]
> in the draft gives a security proof of CCM and states that the  
> adversarial
> advantage, with a tag length of 128 bits and a cipher block size of  
> 128
> bits is a function of:
>
>    (qf * 2^-128) + (lE + lF)^2 * 2^-128
>
> where qf is the number of forgery queries, lE is total number of
> applications of the block cipher in queries to the encryption  
> oracle and
> lF is the total number of applications of the block cipher for queries
> to the forgery oracle.
>
>   P_MAX plaintext is 2^22-1 applications of the block cipher and A_MAX
> additional authenticated data is 2^62-1 applications of the block  
> cipher.
> That seems like it is quite far past the "safe" point. Or what am I
> missing?

Hmm, with lE = 2^22 and lF = 2^62, (lE + lF)^2 * 2^-128 < lF^2 *  
2^-127 = 1/8.  So this is close to the point where the adversaries  
advantage is equal to 1/2, which is typical.

Granted, that's not at the "safe" point.  There is good consensus in  
the crypto community that we should not go beyond that point.    
However, I don't think that there is good consensus on exactly how  
close to that point we should go.  That a valid area for discussion  
and research, IMO.

Best regards,

David

>
>   thanks,
>
>   Dan.
>
>
>
>
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg