Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm creating an SSL cert for my IIS server and need to know when I should choose the Microsoft RSA SChannel Cryptographic Provider or the Microsoft DH SChannel Cryptographic Provider.

Question 1 Why would someone still need (what I assume is) a legacy certificate of 'DH'?

Given that the default is RSA/1024, I'm assuming that is the most secure choice, and the other one is for legacy reasons.

Question 2 Is there any guide to determine what bit level is appropriate for x device?

I'd be interested in either lab results, a math formula, or your personal experience. I know the different bit levels influence the time needed to secure an SSL session and that is important for low powered devices.

Question 3 How would bit-strength affect these scenarios?

My particular case involves these communication patterns:

  1. A website that has powerful clients connecting and disconnecting the session frequently

  2. A WCF website that sustains long durations of high IO data transfers

  3. A client facing website geared for iPhones, and Desktops

share|improve this question
up vote 15 down vote accepted
  1. RSA and Diffie-Hellman (DH) are just two different algorithms which accomplish a similar goal. For most purposes, there is no overwhelming reason to prefer one algorithm over another (RSA vs Diffie-Hellman). They do have somewhat different performance characteristics. RSA is the standard choice, and it's a fine choice.

  2. It's hard to give a one-size-fit-all recommendation on key size, because this is likely to be dependent upon your site's security needs, and because the key size affects performance. My default recommendation would be to use a 1536-bit RSA key. 1024-bit RSA keys should be an absolute bare minimum; however, 1024-bit RSA keys are on the edge of what might become crackable in the near term and are generally not recommended for modern use, so if at all possible, I would recommend 1536- or 2048-bit RSA keys.

    Note that many CAs have recently started deprecating 1024-bit end-entity certificates, as of December 31, 2010: they may issue you a cert for a 1024-bit RSA key, for legacy purposes, if you ask, but they are encouraging people to transition to 2048-bit RSA. Some CAs are requiring 2048-bit keys, no exceptions. Personally, I think 2048-bit RSA is overkill for most purposes and 1536-bit RSA is probably fine, but 2048-bit RSA is accumulating some inertia.

  3. The larger the key, the slower initial connection establishment will be. The most likely impact is on your server's load, since the server has to do a few public-key operations for each new device that connects to it (within a 24-hour period or so). The public-key cryptography only incurs a one-time cost, which is paid once when a connection is created (and not paid again for any new connection within about 24 hours or so); the amount of data transferred over the connection is not relevant.

So, my default suggestion would be: select a 1536-bit RSA key, then test on a typical-low end client (e.g., an iPhone) to make sure performance is OK, then test whether your server can handle the number of connections per day associated with that key size. If you have performance problems on the server, consider a crypto accelerator to speed up your server's performance. If you still have serious performance issues, you could consider dropping down to 1024-bit RSA. If you have a security-critical site, like a banking site, use 2048-bit RSA.

share|improve this answer
    
Thank you for this great answer. Does the volume (Gigs) of data transferred over an SSL connection increase the likelihood that a connection will be hacked? – LamonteCristo Mar 16 '11 at 6:37
3  
Data point: on my PC (2.4 GHz Core2, not the biggest PC ever), OpenSSL happily performs 240 private key operations per second with RSA-2048, using a single core (so close to a thousand per second on the four cores). Consequently, you need quite a lot of clients to actually notice the increased load, when going from RSA-1024 to RSA-2048. – Thomas Pornin Mar 16 '11 at 17:15
    
@Thomas - I'd like to do some benchmarking like this on my Azure host. Any tips on how to implement the test? – LamonteCristo Mar 16 '11 at 21:26
    
@makerofthings: I have very little knowledge of Azure, but apparently it can be programmed in C#/.NET; so you could write a little application that does RSA private key operations, with the System.Security.Cryptography.RSACryptoServiceProvider class. Do a few operations as warm-up, then a bunch of them (say, one thousand) while measuring the time spent for that (with DateTime.Now, before and after the batch). – Thomas Pornin Mar 17 '11 at 11:41
1  
@makerofthings: Good question. No, the amount of data transferred over an SSL connection does not increase the likelihood that it will be hacked. Modern cryptography is good enough that you'll run out of patience long before it hits any limits on the amount of data that can be safely encrypted with one key. – D.W. Mar 18 '11 at 2:23
  1. DH and RSA are different public key algorithms, but there is no appreciable difference in security given equal public key sizes. DH certificates are fairly uncommon, and you don't need to worry about them.

  2. The time needed to perform an RSA operation increases approximately as the cube of the modulus size, i.e. a 2048-bit key is about 8 times slower than a 1024-bit key. This mostly affects the server's performance in SSL, because RSA public operations (decrypt, sign) are much faster than private operations (encrypt, verify) and the client only needs to perform a public RSA encryption using the server's public key in most ciphersuites.

  3. In your first case, performance would be strongly affected by the use of SSL session resumption. If a client reconnects to the same server using SSL, it has the option of "resuming" a previous session, which allows it to skip the expensive RSA key exchange. In the second case, long-duration transfers are not affected at all by the server's key size, since application data in SSL is encrypted with a symmetric cipher, not the server's RSA key. For the third case, see (2) above.

share|improve this answer
    
Is an RSA Public operation "decrypt and sign" really private operations, since they are done with the server that has the private key? Secondly (to verify), is it true that an increased key length will put a greater burden on the client? – LamonteCristo Mar 16 '11 at 15:49
1  
Yes, I mistyped above; decrypt and sign are the private operations, while encrypt and verify are the public ones. An increased key length will increase the burden on clients, but usually this is not considered significant because (1) RSA encryption on the client side is usually not a limiting factor because of the relative speed of RSA public ops, and (2) typically each client only needs to deal with one SSL session, as opposed to an SSL server which concentrates the load from many sessions. I'd suggest benchmarking your client against RSA-2048 to see for yourself. – Tom Wu Mar 16 '11 at 19:59
    
A tiny nitpick: your "8 times slower" comment is a loose approximation. The actual slowdown is a bit less. I just ran a test with "openssl speed rsa512", "rsa1024", and "rsa2048"; rsa2048 was 6.2x slower than rsa1024, and rsa1024 was 5x slower than rsa512. That said, your general point is well taken. – D.W. Mar 18 '11 at 2:28
  1. I do not believe the Diffie-Hellman (DH) choice is legacy, which means obsolete and superseded, it just is not used very often. In my opinion, that's because it's not the first one in the dropdown when choosing your Cryptographic Service Provider when making a certificate request. If someone is actually doing their homework when they make their choice, however, they still would probably not choose DH. According to Microsoft, the reason to choose one or the other is that you would:

"Select Microsoft DH SChannel Cryptographic Provider when you must exchange a secret key over a network that is not secure and you have had no prior communication with the other party."

Reference: https://technet.microsoft.com/en-us/library/cc725579%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396

To me, this would also lead most to just use RSA, since usually you are not exchanging keys across an unsecure network - you are passing your key to your Certificate Authority using your intranet (if self-signing) or perhaps encrypted e-mail or across SSL when communicating to a 3rd-party provider certificate issuing site. Why get something more luxurious/non-standard when you don't need it?

  1. and 3. My personal experience is when you have a longer bit length, you need more processing time/speed/power to decrypt your communication. This means more load on the server, more potential for the memory buffer getting clogged while processing, spiking the CPU/RAM, etc. You have to balance this with the need for secure communication. Generally, you want to get the highest bit length your hardware can handle, which will usually be a function of the security needed for your organization - i.e. generally banks, financial institutions, government agencies, etc. will shell out more money for the kind of hardware needed to support the higher bit lengths (2048+) because of the sensitivity of the information. Higher than 2048, however, can give poor performance on your standard, off-the-shelf server hardware, i.e. those servers that are built at the minimum operating specs the Operating System builder recommends to run their server OS. My experience is anything less than dual-core processors, 4 GB RAM, will give you issues for even just starting the site with bit lengths > 2048.

And, of course, you also have to balance your bit-length and specs against your expected user base and concurrent connections, which has a formula of:

Concurrent Connections = Number of Sessions Per Hour x Average Session Duration (in seconds) / 3,600

Reference: http://support.loadimpact.com/knowledgebase/articles/265461-calculating-the-number-of-concurrent-users-to-test

I don't know the direct correlation between this number and CPU GHz you might want - or if this exists as a standard ratio you want to adhere to, since it will likely vary based on CPU architecture, cache/buffer size, FSB, manufacturer (AMD vs. Intel), etc. But I think it's obvious that the higher the number, the more RAM you'll need to prevent the CPU from getting bogged down, and faster CPU speed you'll need to keep up with the demand. Obviously the amount of data being served up contributes to this factor - the time this takes to be served is called latency, and the less latency you have (faster internal network) and more data being transmitted, it can be too fast and too much for your CPU to process over SSL if it is not beefy enough to work (read, encrypt) under the demand.

For your individual questions under Question 3:

  1. A website that has powerful clients connecting and disconnecting the session frequently

This has implications on the encryption ramp-up on the server-side, but the disconnect cost is really nothing, as far as SSL goes - it's like a light switch being shut-off. And this goes back more to the number of connections that start connecting simultaneously. You'd monitor your CPU and RAM usage during the connection openings and if it's spiking those in your Process Monitor, you know you might need either a lesser bit-length or more resources, or both.

  1. A WCF website that sustains long durations of high IO data transfers

This depends - are the transfers a single request with a lot of data behind them, or many transfers with small packets? The former is usually easier on the CPU/RAM than the latter. You're also talking more about bandwidth than the encryption processing, since that will more than likely be your bottleneck more than the processing power taken by SSL encryption/decryption.

  1. A client facing website geared for iPhones, and Desktops

If we're talking phones, we're talking 4G connection, which is probably going to be your bottleneck more than its processing power to decrypt the bits, as long as we're talking 2048 or lower. A site geared for a phone is generally going to have fewer graphics/data involved if the programmer is worth their salt, so there should be less to encrypt and transfer. A site for a desktop is a different animal since the desktop will usually be hard-wired to a network, and will (generally) have more processing power than a phone. For the server, it's still about CPU/RAM vs. bit length to process/serve the SSL encrypted bits, and it's going to be different if you're talking about a mobile-geared site vs. a standard site. A mobile-geared site should (theoretically) have less bits to encrypt, therefore take less processing power, allowing a higher bit length. The opposite would apply for a full, desktop-geared site.

share|improve this answer

This page has some interesting benchmarks that show the effect of key size on performance: https://securitypitfalls.wordpress.com/2014/10/06/rsa-and-ecdsa-performance/

share|improve this answer
    
This answer needs expansion and explanation. As it stands right now it'll get down voted for not adhering to Stack Exchanges policy for answers. Try to provide some bullet points and explain how the information in this link is helpful. After all, some day in the future the link won't exist any more and then this answer will be useless. – Robert Mennell Nov 9 '15 at 19:38
  1. Because many clients don't support better technology.
  2. Yes there is. By now RSA/2048 is considered default secure bit-length. There are conversion tables for bit-rate security for different PKC algorithms, but those are not really sepcific cause every new research in the field changes those. There are approximate coefficients.
  3. The bit-length affects time of key generation exponentially, Key generation and SSL establishment is only done at the beginning of every secure connection and data is not encrypted with that, So IO transfers don't affect it. Frequent connections might put extra load on server, thats why loaded sites don't offer SSL for default. Check which bit-length/algorithms iPhone supports. Desktops have no problem.
share|improve this answer
1  
your answer to 1. isn't quite right. It's not the case that Diffie-Hellman is some legacy algorithm that is more widely supported by clients. Also, your answer to 3. has some issues. Bit-length does not affect key generation exponentially. Also, key generation time is generally irrelevant, because it is done only once, when the server is set up. – D.W. Mar 16 '11 at 5:49
    
@D.W: please refer to the order of generating a RSA key. – AbiusX Mar 16 '11 at 14:31
    
huh? I don't follow you. – D.W. Mar 18 '11 at 2:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.