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.
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?
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 ?
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..