[Cfrg] Providing guidance on the choice of symmetric key length?

Hi,

Sorry to bother you with a another somewhat naive question I stumbled 
across while trying to work on an EAP method (EAP is RFC 2284 revised by 
2284bis)

In short, when using a symmetric key cryptographic primitive (namely a 
block or a stream cipher), you may have to choose (among other 
parameters) the key size. This is indeed the case with say AES, since 
according to FIPS 197, you may use a 128, 192 or 256 bit keys. The 
question is: what key length should be chosen (arguably, since this 
choice may depend on the target application in which the primitive has 
to be used, let's say for an authentication protocol used over the 
Internet).

This seems to be quite a dumb question, since the answer is IMHO 
folklore: 128 bits is OK for most (all?) applications.

My point is that I surprisingly did not find any simple and clear 
reference to which (non-expert) people working at IETF could be pointed 
to, regarding the choice of symmetric key length.

Any feedback would be most welcome.

Many thanks in advance,
Florent, who perhaps has a very stringent definition of simple and clear 
reference ;-) and agrees that his question is not a very good one :-( 
Just wanted to make sure

Indeed, the references I consulted before daring to turn to the CFRG 
include:

    * "Handbook of Applied Cryptography" by Menezes et al.: chapter 1 on
      (§1.13.4) and chapter 7 on block ciphers (§7.2.1 (iii), 7.2.3 and
      §7.8)
    * "Applied Cryptography" by Bruce Schneier, part II chapter 7 (key
      length)
    * "Minimal Key Length for Symmetric Ciphers to Provide Adequate
      Commercial Security. A Report by an Ad Hoc Group of Cryptographers
      and Computer Scientists", M. Blaze, W. Diffie et al., Jan. 1996.
    * "Selecting cryptographic key size" by Lenstra and Verheul, 2001,
      http://citeseer.ist.psu.edu/287428.html
    * "A Cost-Based Security Analysis of Symmetric and Asymmetric Key
      Lengths", RSA Laboratories Bulletin 13, April 2000 (Revised
      November 2001),
      http://www.rsasecurity.com/rsalabs/bulletins/bulletin13.html
    * "Determining strengths for public keys used for exchanging
      symmetric keys", H. Orman and P. Hoffman, RFC 3766
    * "The AES-CBC Cipher Algorithm and Its Use with IPsec", S. Frankel
      et al., RFC 3602

Generally, these references rather aim at studying public key length 
compared to symmetric key length and usually consider my question as a 
simple side problem, e.g. in RFC 3766 "While it is fairly easy to 
express the system strength requirements in terms of a symmetric key 
length".

I agree that it is not hard to become aware that there seems to be 
consensus that a 128 bit key with a (good) block cipher is OK (e.g. in 
RFC 3766 "In this section, for illustrative purposes, we will implicitly 
assume that the system security requirement is 112 bits; this doesn’t 
mean that 112 bits is recommended. In fact, 112 bits is arguably too 
strong for any practical purpose. It is used for illustration simply 
because that is the upper bound on the strength of TripleDES") and that 
some reference do provide explicit estimates for symmetric key size choice.

The naive question that however logically puzzles the curious (and 
not-expert in cryptography) protocol developer is why then do we have 
the choice to use a larger, say 256 bit, key?

Possible answers I thought of include:

    * It is a good idea to be conservative in cryptography and to allow
      for larger key sizes (but then why shouldn't I be conservative
      myself and not use AES-256?)
    * You may use larger key size but performance will degrade (a quite
      complete performance report to back up/infirm this claim seems to
      be the NESSIE deliverable 21 e.g. table 31,
      https://www.cosic.esat.kuleuven.ac.be/nessie/deliverables/D21-v2.pdf).
      However, depending on the application, performance may not be that
      much of an issue (e.g. an authentication protocol probably does
      not have the same performance requirements for its primitive as a
      "bulk data encryption protocol" - like ESP) and degradation may be
      very little (see e.g.
      http://www.ietf.org/proceedings/01dec/slides/ipsec-11.pdf).
    * You may use larger key size but you will have export regulations
      problems (for example, in France, 128 bit is a threshold, see
      http://www.ssi.gouv.fr/fr/reglementation/regl_crypto.html)

(An additional reason I was indicated for having larger key size could 
be when the key has an "entropy" that is not equal to its length but 
this seems IMHO a rather deviant and bad reason to use a 256 bit key 
block cipher with 256 bits that are chosen at random from say a 2**128 
space. I'd prefer to have the "bad" 256 key bits pre-processed and then 
used in a 128 bit block cipher)

After reading references like draft-ietf-ipsec-ciph-camellia-01.txt or 
RFC 3602, security considerations section:
"Implementations are encouraged to use the largest key sizes they can 
when taking into account performance considerations for their particular 
hardware and software configuration. Note that encryption necessarily 
impacts both sides of a secure channel, so such consideration must take 
into account not only the client side, but the server as well. However, 
a key size of 128 bits is considered secure for the foreseeable future", 
I still find it hard for a protocol developer to choose ;-)

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg