RSA key length choice for TLS when confidentiality not important?

Question

I've a couple of questions about this, the scenario is embedding a key pair in a hardware device which will speak with other hardware devices over tls. computing resources are an issue so i want to make intelligent choices about where they go on. We're using TLS to authenticate one device to another, and to ensure integrity of messages in transit. Immediate or long term confidentiality of messages is not a consideration.

1. All the recommendations are in the case of RSA to use 2048 bit keys because that will be secure until 2030. However, in my application the RSA key is used only to provide a TLS handshake for the lifetime of that key on that device, so it doesn't need to remain secure until 2030. The AES session key is renegotiated every 24 hours and beyond that it doesn't need to be confidential. TLS is being used to ensure integrity in transport only, the communicated data doesn't need to be confidential.

   I'm aware 768 bit numbers have been factored, but my understanding is that factoring one 768 bit number does not help much to factor other 768 bit numbers. I haven't found docs to say how long it takes to factor a number of X bits with equipment Y. As an an example I'm going to say 5 years with budget X and equipment Y to factor 768 bits - then people can tell me if the following analysis is solid or not.

   E.g. my device will be in use for the next 5 years. I choose RSA 768 as key size and I change the keys every 12 months. From day 1 an attacker tries to do every attack he can on the TLS crypto. After 2.5 years technological advances mean he can recover my RSA year 1 private key. However the year 1 can no longer be used to establish a TLS session so there's no impact there. The attacker can also recover the session keys of year 1 which were negotiated with the RSA year 1 key, but as the confidentiality of year 1 data wasn't important there is similarly no impact.

   So given this why aren't RSA key size recommendations given in terms of attacker motivation, key lifetime, key usage rather than blanket recommendation of 2048?

2. Practicalities of generating keys / certs on build machines. Being conservative I'd say this should be avoided, would it be reasonable to generate device keys via an OpenSSL script with FIPS options on an up to date build machine with appropriate controls, or should there be a hardware crypto-module ? Or put another way, would an expert witness lambast us in some possible future court case if we had generated device keys in software on a build machine or is that a reasonable way to go about things ?

3. If I tried to factorize RSA 768 on my home PC and I was a competent mathematician, how long would it take me? Same question but I have access to a computing cluster. It seems that in 2009 the factorizing took 3 years, 6 labs, many mathematicians and hundreds of computers..

Answer 1

1. To clarify: The critical time period here is one year (after wich the certs are changed). With the cracked RSA key the attacker can decrypt the traffic and do nan-in-the-middle attacks, posing as a valid hardware device.

Let us take the numbers determined by experts. In their paper on cracking the 768-bit RSA key the researchers state that they needed about $2^{67}$ instructions. When you look up current pricing for the Amazon EC2 cloud you get two Intel Xeon E5-2670 for 2.4\$ per hour. That is roughly $$2 CPUs \times 3\ GHz \times 8\ cores \times 8 FLOPS/cycle = 384\ GFLOPS$$ for 2.4\$/hour. That makes the cost of cracking a 768-bit RSA key about a quater million Dollars (on CPUs). Or 143 instances working for one month, or 1000 instances working for 4 days, etc. This is of course very simplified but gives you a rough idea.

Computing power doubles every 2 years and with special hardware, like GPU computing you can significantly lower the pricetag (modern cards operate in the order of TFLOPS see specs on AMD or NVIDIA websites).

A computer packed with 3 GeForce GTX 780 Ti (cost all together about 3000\$) can achieve 15 TFLOPS. This cracks a 768-bit key in 113 days, well under one year. So your key is definitly not safe from a moderatly determined attacker.

As for a 1024 bit key they state it would take 1000x more time or money. Very costly, but totaly out of reach in 5 years?

Other sources state a 2048 bit key would take $2^{32}$ times longer. So you are definitly save here.

But if I understand your scenario correctly you might be able to avoid the problem altogether: The computing cost of a larger RSA key only has to be paid once. During the inital handshake of the connection (generating the AES key). If you do not have a higly dynamic environment (meaning devices coming and going all the time) this cost will not matter much.

2. For generating a few certificates a year you do not need a special module. This is only neccessary if you need massive amounts of randomness/entropy (e.g. if you need to produce a cert every second). Here is command to find out the (estimated) entropy of your system on Linux:

cat /proc/sys/kernel/random/entropy_avail

I would be more worried about the entropy available on those hardware devices (needed for the TLS handshake). If they are very simple microcontroles that might be a problem.

3. Kind of answered that in question one.

Hope that helps!