Whenever you generate a server key on JSCAPE MFT Server, you're asked to specify a key length. Since longer keys translate to stronger security, choosing the longer key length might seem like a no-brainer. But why did JSCAPE have to include an option for a shorter key then? Will there be instances where you'll have to choose the shorter key? The answer is yes. And in this post, we'll explain when that can be the case.
Before we get to that part, I'd like to talk about the downside of using longer encryption keys, which was quite evident in an experiment I did very recently.
Longer encryption keys are more computationally expensive
I conducted a series of tests using JSCAPE MFT Monitor and JSCAPE MFT Server to compare the performance of certain secure file transfers using two different key lengths: an RSA 1024-bit key length and an RSA 2048-bit key length. I ran one set of tests on an FTPS service and another on an SFTP service. Both FTPS and SFTP employ server keys to encrypt files during file transfers.
Here are two screenshots from the tests made on the SFTP service. The first screenshot shows the result from one test run using a 1024-bit key, while the second shows what I got on one run using a 2048-bit key.
JSCAPE Load Tester sample Summary when using 1024-bit key length
JSCAPE Load Tester sample Summary when using 2048-bit key length
Naturally, I got slightly different results on each run, so I took a bunch of related results (i.e., same service, key length, and number of users) and averaged each statistic.
For this post, we're particularly interested in one statistic: the average of the "average connect time". The connect time is the time it takes for a connection to be established. Part of the process of establishing a connection for secure file transfer services like SFTP and FTPS is the negotiation of the session key, which is initially encrypted by the public key you create during server key generation. For an FTPS session, which uses SSL, this part is known as the SSL handshake.
The SSL-handshake (as well as the equivalent process in SFTP) is a resource-hungry operation. Furthermore, its appetite grows with key size. For example, in my SFTP tests, the average of the "average connect time" grows by at least 30% if you compare the 1024-bit with the 2048-bit results. This was for the tests where I set the Load Tester's user count to just 1. When I simulated 3 concurrent users, I got a 40% increase in the connect time.
But that's nothing to what I got for the FTPS service. For 3 concurrent users, I got an increase of at least 110%. Interestingly, the increase was relatively negligible (only 4%) when I simulated only 1 user.
Based on the results, I can say that when you double the key length (1024 to 2048) of your public keys, your connection times will take significant hits. In other words, you're going to suffer from longer connection times. And in the case of FTPS connections, the situation quickly deteriorates even more when you have more concurrent users.
How does this happen? Let's take a look at what happens at the start of FTPS connections (SFTP connections also start in almost the same way).
Note: I did this in a lab environment. In a real world scenario, network conditions can get even worse due to latency and packet loss.
How the SSL Handshake impacts connection time
SSL sessions always start with what is known as the SSL handshake. Here are the steps of the handshake in a nutshell. Please note that this is only a simplified version, containing only the portions that are most relevant to this post.
As you can see from the later part of the SSL handshake, the main purpose of the public/private key pair is to encrypt/decrypt what is known as the session key. Once an SSL handshake is complete, succeeding encryption/decryption operations will be carried out by the session key. The session key is a symmetric key, while the public key as well as its private key pair (which is stored in your managed file transfer server) are asymmetric keys.
Decryption is more expensive than encryption
Generally speaking, decryption is slower than encryption. And when you increase the key length, decryption speed slows down even more.
This has large implications on servers because, during the SSL handshake, decryption takes place on the server side. And really, when you talk about servers, you virtually always have a one-to-many relationship. That is, one managed file transfer server will normally cater to dozens, hundreds, or perhaps even thousands of clients.
Get all those clients to initiate SSL connections to your managed file transfer server at the same time, and you might just have a server crash in your hands.
In fact, there's a particular DoS (Denial of Service) attack tool that exploits this particular SSL vulnerability. The tool works by repeatedly requesting the SSL-enabled server to enter into "renegotiation", which forces the server to keep on entering into an SSL handshake.
How to choose the right key length
First of all, if you have a really powerful server with lots of memory and CPU, then certainly going for the longer encryption key all the time should be a no-brainer. However, if you've got limited resources, you might have to be selective when doing file transfers that use long encryption key lengths (or encryption at all).
Try to look into the kind of information you send through your file transfer system. Does it contain data that you need to keep confidential? A good way to start would be to review laws and regulations like SOX, GLBA, HIPAA, PCI-DSS, EU Data Protection Directive, and state data breach notification laws. For all you know, in your case, strong encryption might already be mandated by law.
If you see a regulation that affects you, check if it requires a minimum key length.
Some of the types of information covered by the laws/regulations mentioned earlier include: personal information, financial reporting data, medical records, and credit card information. These types of data will most probably have to be protected with strong encryption.
But there are also other types of information which may not be included there but still require optimal protection. Things like secret formulas, source codes, salaries of key managers, strategies, list of customers, list of suppliers, customers with special discounts, student grades, evaluation results, and so on, might be the kind of information you'd like to keep secret.
Once you've determined the kind of information that goes through your file transfer system, do some risk analysis to identify possible risk sources and possible levels of motivation. For example, do you have data that might motivate a hacker, industrial spy, terrorist, or malicious employee to launch any kind of attack on your system?
If the answer is yes, then you may need to go for longer key lengths.
There are no hard and fast rules here. Each organization is unique, so you can use what you've learned here as a guide and then decide for yourself when to use a long encryption key or a short one. I hope we were able to provide you with ample information so you could make an educated decision.