Theoretically, RSA keys that are 2048 bits long should be good until 2030. If so, isn't it a bit early to start using the 4096-bit keys that have become increasingly available in encryption-enabled applications? It depends.
In case you're curious where we got the idea of 2048-bit encryption keys being safe to use until 2030, check out the NIST Special Publication 800-57 Part1. In Table 2 of that document, it says 2048-bit RSA keys are roughly equivalent to a Security Strength of 112. Security strength is simply a number associated with the amount of work required to break a cryptographic algorithm. Basically, the higher that number, the greater the amount of work required.
We have reproduced a portion of that table below for those who want a quick reference. It implies longer keys are more difficult to break and are hence more secure.
|Security Strength||RSA key length|
The same NIST document also has a table (Table 4) that shows the period over which each Security Strength is deemed acceptable. According to that publication, 112 security strength (which corresponds to 2048-bit keys) is considered to be acceptable until 2030. Again, here's a portion of that table for reference.
|Security Strength||Through 2030||2031 and beyond|
Alright. So now we know 2048 bit keys are indeed acceptable until 2030 as per NIST. So where does that put our 4096 bit keys? Incidentally, the document is silent about this particular key length. However, because the two tables indicate that 3072-bit keys (whose security strength is 128) and 7680-bit keys (whose security strength is 192) are good beyond 2030, we can safely say 4096 bit keys (which are somewhere in between) should likewise be considered secure enough then.
In fact, since 2048-bit keys are supposed to be disallowed after 2030, we know for certain that 4096 bit keys are going to be more suitable in production environments than 2048 keys when that time comes. But since we're still at least a decade away from 2030, it's probably not yet necessary to migrate from 2048 to 4096, right?
So why then are we already seeing options for 4096-bit keys in some security applications?
4096-bit key provided as an option during server key generation on JSCAPE MFT Server v10.2
Well, there could be a couple of reasons. One is simply to make the application future proof. A future proof security solution can mitigate the risk of cyber threats. We know that cyber criminals are always one step ahead of security professionals, so we're not 100% sure 2048-bit keys are going to remain unbreakable before 2030.
But if the more secure 4096 keys are already available and it's just a matter of clicking the 4096 option, what should stop us from doing just that? One factor that needs to be considered is performance. Longer keys take more time to generate and require more CPU and power when used for encrypting and decrypting. So, in the case of file transfer servers, if your physical server is relatively old and has limited computing resources, then 4096-bit keys may impact your server's performance.
Actually, secure file transfer protocols like HTTPS, FTPS, or SFTP normally use RSA keys only during the start of the connection, when they're used in encrypting the symmetric keys. Once you start transmitting the data, it's going to be the symmetric keys that are going to be used in the subsequent encryption processes.
So, the performance hit due to a 4096-bit key will only be felt within a small fraction of the entire file transfer session. Of course , if your server carries out a large number of concurrent file transfers, then the performance hits can add up. But just how significant are these performance hits? That would depend on several factors like your server's CPU, the number of concurrent file transfers, network bandwidth, and so on.
In other words, the impact on performance would vary from one scenario to another. The best way to determine if the performance hit would be substantial in your particular environment would be to run actual tests.
JSCAPE MFT Server v10.2, which is due for release on December 8, 2017, already supports 4096-bit keys. So if you want to run some tests against it to see if the performance hits are substantial in your specific environment, then you may download an evaluation edition as soon as it's available. We shall update this blog post with a download link once version 10.2 is out.
You can run performance tests against that JSCAPE MFT Server instance using the load testing feature of JSCAPE MFT Monitor. We've written a blog post featuring a rudimentary load testing session involving key lengths some time in the past. To get some ideas from there, read the post:Choosing Key Lengths for Encrypted File Transfers