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 about 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. Table 2 of that document says 2048-bit RSA keys are roughly equivalent to a Security Strength of 112. Security strength is simply 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 |
| <= 80 | 1024 |
| 112 | 2048 |
| 128 | 3072 |
| 192 | 7680 |
| 256 | 15360 |
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 strengths (corresponding to 2048-bit keys) are considered acceptable until 2030. Again, here’s a portion of that table for reference.
| Security Strength | Through 2030 | 2031 and beyond |
| < 112 | Disallowed | Disallowed |
| 112 | Acceptable | Disallowed |
| 128 | Acceptable | Acceptable |
| 192 | Acceptable | Acceptable |
| 256 | Acceptable | Acceptable |
Alright. So now we know 2048-bit keys are 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 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 to make the application future-proof. A future-proof security solution can mitigate the risk of cyber threats. We know cybercriminals are always one step ahead of security professionals, so we’re not 100% sure that 2048-bit keys will 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 that?
Considering the future of your encryption needs? Discover how JSCAPE MFT Server’s support for 4096-bit keys can secure your file transfers against future threats.
Experience the difference by trying our award-winning MFT solution for free when you request a free trial. Stay ahead of cybersecurity challenges with JSCAPE.
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 many concurrent file transfers, then the performance hits can add up. But 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, etc.
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, 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, 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
Get Started
- Request a free trial
- Connect with a JSCAPE product expert
- Test JSCAPE MFT Server, a multi-protocol, platform-independent managed file transfer solution users are most likely to recommend, according to G2.