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
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
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");
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
- 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
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
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.