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");
gen.init(256);
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)¹ 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)² recommend using a 256-bits key size (p 65).
• NIST (2006)³, 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:

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 2¹⁶⁰ period— in other words, it can only generate 2¹⁶⁰ out of the 2²⁵⁶ 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.