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

[Daniel Brown <[e-mail]>]

Florent,

Although it may not answer your question fully, another useful document 
that speaks about key sizes is NIST draft Special Publication 800-57, Part 
1, (see http://csrc.nist.gov/CryptoToolkit/kms/guideline-1-Jan03.pdf). 

Specifically, Table 9, pages 98-99, states what symmetric key sizes NIST 
believes to be appropriate for data that needs protection continuing in 
the future.  It rates AES 128, 192 and 256 as appropriate for data needing 
protection beyond 2035, but it does not distinguish any further between 
these 3 key sizes.  (Arguably, it would be too speculative to forecast any 
farther into the future.)  It does suggest that TDES is only appropriate 
for data needing protection up to 2035 but not farther. (I've heard that 
2035 will be corrected to 2030.)

Thanks,

        Dan

PS For what little it's worth, although I agree in principle that one 
should use the highest security feasible, I'd also agree that 128-bit 
security is good enough for nearly everybody.  Reasons for 192 or 256-bit 
security instead of 128-bit include protecting extremely sensitive 
information, long-term protection (40, 50, 60+ years from today), worries 
that forecasters have underestimated computing advances in the next 25 
years by a large factor (about 2^64 or more), a willingness pay for the 
extra cost of larger key sizes today as a kind of insurance that may or 
may not pay out.




[e-mail] wrote on 05/03/2004 11:08:37 AM:

> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/cfrg