Java tutorials home  Java cryptography  Encryption intro  Keys  Symmetric encryption  AES/block ciphers  Block modes (ECB, CTR, OFB)  Asymmetric encryption  RSA in Java  Comparison of algorithms  Key sizes  Hash functions

Search this site:
Threads Database Profiling Regular expressions Random numbers Compression Exceptions C Equivalents in Java

Key size

As well as choosing an encryption algorithm, you must generally choose a key size to use with that algorithm. In a loose way, the key size determines the "strength" of encryption, assuming that the actual algorithm is otherwise secure. Specifically, the key size generally determines: the number of guesses that an attacker would need to make in order to find the key by "brute force", assuming that all possible keys are equally likely. Relatedly, it also determines the chance and feasibility of a collision attack.

Note that on this page, we are concerned with the key size of symmetric encryption algorithms— that is, where a shared secret key is used by all parties. In geneal, asymmetric algorithms require a larger key size measured bit-for-bit. We discuss RSA key sizes on a separate page.

How to set the key size in Java

If you use the KeyGenerator class, then you can set the key size in bits via the init() method. The following example shows how to generate a 256-bit AES key:

KeyGenerator gen = KeyGenerator.getInstance("AES/CTR/PKCS5PADDING");
SecretKey k = gen.generateKey();
Cipher ciph = Cipher.getInstance("AES");
ciph.init(Cipher.ENCRYPT_MODE, k);

Note that attempting to use this key with Sun's JDK "out-of-the-box" will throw an InvalidKeyException due to an (overridable) policy restriction that limits symmetric keys to 128 bits. Below, we describe how to remove this 128-bit description, and how to determine if a given client has this restriction.

Which key size?

In general, the minimum required key size is some combination of the maximum key size that can be attacked now for a given algorithm, extrapolated to the number of years that you need to keep the encrypted data confidential. Needless to say, such extrapolation is extremely difficult beyond a few years. A couple of pointers are:

  • Lenstra & Verheul (2001)1 take data points from attacks on keys of various lengths and extrapolate via Moore's Law. They conclude that in 2030, it will seem as difficult to brute-force a 93-bit symmetric key as it did to brute-force DES in 1982, and that in 2050 this will be true for a 109-bit key. From this, we might conclude that, ignoring collision attacks, a 128-bit key is sufficient to keep data confidential for the next few decades.
  • Taking into account collision attacks, Ferguson & Schneier (2003)2 recommend using a 256-bits key size (p 65).
  • NIST (2006)3, presumably based on similar types of calculation, recommend a minimum of "128 bits of strength" (p. 66) to keep data confidential "beyond 2030".
  • The Visa credit card company's Data Field Encryption best practices guide suggets that for the purpose of transmitting credit card numbers, "keys should have the strength of at least 112 equivalent bit strength". For this purpose, they actually judge 128 bits (as in the minimum AES key size) to be "stronger than needed" (presumably because of the relatively short lifespan of credit cards).
  • In principle, a quantum computer could square root the effort of a brute-force key search, so that the bit strength of the key is halved (i.e. a 256-bit key in quantum computing has the strength of a 128-bit key in classical computing).

The conclusions I draw from this are:

  • if possible, use a 256-bit key; if no great revolution occurs, this will probably keep your data safe for at least 20 or 30 years;
  • a 128-bit key may be suitable if you've thought carefully about collision attacks and how they affect the future of your data and application, and if you don't see quantum computing as a threat within the lifetime of your data (in the transmission of credit card details, for example, it seems a fairly safe bet that all existing cards will have expired by the time practical quantum computers become a reality!).

Practical problems with using 256-bit keys in Java

There are a couple of practical problems with using 256-bit keys in Java:

  • current versions of the JDK ship with a 128-bit policy restriction on key sizes;
  • the SecureRandom generator has a 2160 period— in other words, it can only generate 2160 out of the 2256 possible 256-bit keys.

If your deployment model allows it, the 128-bit restriction can be removed by downloading and manually installing Unlimited Strength Jurisdiction Policy Files provided by Sun.

1. Lenstra, A. K. & Verheul, E. R. (2001) Selecting Cryptographic Key Sizes, Journal of Cryptology 14(4):255-293.
2. Ferguson, N. & Schneier, B. (2003), Practical Cryptography, Wiley.
3. NIST (2006), Recommendation for Key Management: Part 1, NIST.

comments powered by Disqus

Written by Neil Coffey. Copyright © Javamex UK 2012. All rights reserved.