数据加密-怎样确定RSA Key 的长度

RSA key lengths

From http://www.javamex.com/tutorials/cryptography/rsa_key_length.shtml

When you create an RSA key pair, you specify a key length in bits, as generally you would for other algorithms. Specifically, the key length of an RSA key specifies the number of bits in the modulus. In our RSA encryption example, we specified a key length of 2048 bits. But in practice, what RSA key length should we choose?

First the short answer:

• a RSA key length of 1024 bits is sufficient for many medium-security purposes such as web site logins;
• for high-security applications¹ or for data that needs to remain confidential for more than a few years, you should use at least a 2048-bit key, and consider having a contingency plan for migrating to larger key sizes;
• to keep data confidential for more than the next two decades, RSA recommends a key size larger than 2048 bits (see below).

So, why not just make the key much longer, say 4096 bits or even 8192 bits? Well, as usual, there's no such thing as a free lunch. A larger key increases the maximum number of bytes that we can encrypt at once, and also the security of the encryption. But it has a serious problem in practice:

With every doubling of the RSA key length,  decryption is 6-7 times times slower.

Figure 1 shows how decryption time increases with modulus length. The timings were made on a 2GHz Pentium.

Figure 1: RSA decryption time by key length.

The key length also affects the speed of encryption, but it's usually the speed of decryption that we're more concerned about because (a) that's the part that takes place on the server, and (b) decryption is much much slower than encryption, because the decryption exponent is huge (whereas the encryption exponent is typically small).

If we use a 4096-bit modulus, it takes around a second of CPU time to decrypt a block of data. Even if you were able to sacrifice this amount of CPU to every log on, it leaves us with the problem that an attacker can effectively burn a second of CPU time on our server by firing some random data at it. With a 1024-bit key length, decryption takes just 25 milliseconds; with suitable restrictions on the rate of login attemps (and thus decryptions) we allow per remote client, protecting against a "CPU burn" attack is more feasible.

How secure is an n-bit RSA key?

As ever, judging the security of a key of a given size is a complex issue. With current knowledge, "breaking" an RSA key by brute force effectively means factoring the modulus. The largest number that has been factored publically to date is RSA-640, a 640-bit number put up as a challenge by RSA and factored in 2005. This number took "only" around 350 CPU hours (using a cluster of 80 2.2 GHz Opterons). Put another way, you can rent that CPU time from Amazon for about 50 dollars. This is a simplistic view: it doesn't take into account memory and data transfer requirements. And the experimental software used by the team isn't exactly a "plug and play RSA cracker": it surely requires considerable configuration by somebody well versed in number theory.

Factoring RSA 512-bit keys is now squarely within the reach of anyone who is determined enough. As testimony to this, several 512-bit RSA keys used to sign the operating systems of Texas Instruments calculators were recently factored, reportedly within "several months".

So what about 1024-bit keys? Generally, this size will keep your data safe now from an adversary with modest resources. But it's not sufficient for keeping data confidential much into the future, or for keeping it secret from an adversary prepared to devote a few million dollars to the problem. To see why, we'll look below at some estimates on the difficulty of breaking 1024-bit RSA encryption.