Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

3 Answers 3

up vote 11 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? –  makerofthings7 Mar 16 '11 at 6:37
2  
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? –  makerofthings7 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. 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
  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? –  makerofthings7 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

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.