Subject: [Cfrg] expectations for security claims and guidance

From: David McGrew <[email-masked]>
Date: Wed, 5 Oct 2005 08:35:35 -0700

Hello,

I'd like to ask for your input on an important issue that has come up  
recently: our expectations for the security claims and guidance in  
crypto specifications.  By specifications, I mean documents generated  
by the IRTF, IETF, or other organizations whose main purpose is to  
provide a stable, normative definition for implementers and other users.

Ideally, we'd like to have security claims that are precise and  
explicit.  If an algorithm is provably secure, we'd like to know all  
of the assumptions in the proof, the properties claimed, and actual  
values of the deltas and epsilons.  Certainly the crypto community  
should require this sort of rigor.  But does it belong in a  
specification?   It is applying a standard that is much higher than  
the one that was applied when the specs for the crypto algorithms  
currently in use were created.

The precedent so far has been to rely heavily on security analyses  
and usage recommendations that are external to the specifications  
themselves.  IIRC, the "Recommendation for Block Cipher Modes of  
Operation", NIST Special Publication 800-38A, neither makes security  
claims for the modes that it defines, nor provides usage limitations  
on any topic other than IV generation.  For another example, HMAC  
(RFC2104) provides a security discussion, but not a quantitative  
claim such as a bound on forgery probability, and then references the  
peer-reviewed publication that presented and analyzed the design.

We can do more in future standards.  But let's recognize that we're  
consciously raising the bar, and consider how best to move forward.

IMO, guidance on usage is essential.  This guidance ought to be of  
the form "Parameter x MUST be at least y", or "If parameter x is less  
than y, then option z MUST be selected."   I'd like to see this in  
every specification.  If there are multiple security services or  
multiple security levels provided by a spec, then this guidance will  
end up being conditional (and hopefully not too complicated).

For security claims, we face the challenge of making results from  
theoretical cryptography understandable to the layman.  This is quite  
difficult; being half-rigorous is like being half-pregnant.  We could  
require the specifications to include the theorems underlying their  
security claims, and perhaps include the entire definition of the  
security model.  Perhaps this is workable, though any spec that did  
so would need to make sense (and provide security guidance) to a  
reader who chooses to not read those sections.

It might make sense to write a separate document that provides  
definitions of security models, which could then be referenced by  
multiple specifications.  Writing a document like this one would  
promote discussion about security models and definitions, which would  
be a healthy thing.

Another topic worth our consideration is guidance on parameter  
choices to achieve a certain security goal.  For example, how much  
data do we allow to be encrypted with AES-128?  Less than 2^32  
blocks, to ensure indistinguishability?  Less than 2^64?  Any  
number?  What data-processing bound should we recommend for 3DES?     
Should we define different security levels and/or goals, and provide  
guidance for each of those choices?  MACs and authenticated  
encryption algorithms are more complicated, and require more detailed  
guidance.

The CFRG is ideally suited to address these issues, because it has  
participation from both the theorists and practitioners.  We should  
consider writing an RFC to address one or more of these points.

Other viewpoints welcome.

David

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

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Oct 2005 22:19:13 -0000

I don't think IETF is accomplishing anything useful by _requiring_, as
opposed to merely encouraging, a section on ``security considerations.''
In particular, I don't think that a cryptographic function specification
should be censored for failure to say anything about security.

However, once a specification crosses the line into making a security
claim, then it has to state the claim clearly, and it has to honestly
distinguish between what's proven and what's merely conjectured.

Honesty and clarity are compatible with brevity! The standard expository
trick is to use an example, as illustrated by the following paragraph
from the Poly1305-AES paper:

   Guaranteed security if AES is secure. The security gap is small, even
   for long-term keys. Assume, for example, that messages are packets up
   to 1024 bytes; that the attacker sees 2^64 messages authenticated
   under a Poly1305-AES key; that the attacker attempts a whopping 2^75
   forgeries; and that the attacker cannot break AES with probability
   above delta. Then, with probability at least 0.999999 - delta, _all_
   of the 2^75 forgeries are rejected.

The delta parameter is unavoidable: it depends not only on the amount of
computation performed by the attacker, but also on the possibility of a
surprising advance in AES cryptanalysis. Other than delta, everything
has been replaced by concrete, comprehensible numbers.

---D. J. Bernstein, Professor, Mathematics, Statistics,
and Computer Science, University of Illinois at Chicago