Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

There has been some discussion about it being more practical to use SSL due to advances in hardware. From my understanding, stronger public-key encryption means that both encrypting/decrypting and breaking it (via brute-force or vulnerabilities) take longer.

Is the return (in security) for the performance loss of using SSL increasing, or has today's hardware simply outgrown the strength of encryption used?

share|improve this question

2 Answers 2

up vote 7 down vote accepted

There are several effects coming into play. But the most important property is that with increasing keylengths, the attacker's work becomes exponentially expensive, whereas the defenders work only becomes a bit more expensive.

Looking at the different kinds of cryptography in use:

  1. Symmetric cryptography
    Originally we used DES and 3DES. DES had a dangerously small key and decent performance. 3DES had a secure keysize, but bad performance (3 times as slow as DES).
    So AES was developed which has very good performance, and secure key sizes. AES-128 is secure against brute-force for a long time, and AES-256 is secure against brute-force with conventional and quantum computers forever. So unless there are major advances in crypto-analysis, there is no reason to use symmetric crypto slower than AES-256, no matter how fast the attackers computers get. AES performance becomes significantly better on the current generation of processors, which offer specialized instructions.
  2. RSA used in the key-exchange
    The defenders cost grows with the key-size to the third power. The attacker's cost growth much faster, but doesn't double with each bit. So we need to increase key-sizes somewhat to compensate for the increased computational power of attackers. For example 1024 bit RSA keys are currently on the way out, because cracking them will become possible soon.
    Still the defenders advantage grows as computers get faster.
  3. Better asymmetric algorithms
    Elliptic curve cryptography is much faster than RSA. Currently it doesn't get used much for authentication in SSL, only for the ephemeral key-exchange in the DHE suites. But in principle they allow a 128 bit security level at faster performance than 1024 bit RSA keys.

In general modern cryptography is at a level where brute-force is no longer a thread for most schemes. The main trade-off is performance vs. how resilient to crypto-analysis the ciphers are. But even there we're only talking about a small constant factor that doesn't scale with computational power.

Unless there are major advances in crypto-analysis or computer science in general, I expect the processor cycle cost of cryptography to remain approximately constant. This means that effectively it'll get faster at the same rate as our processors.

In particular that means that the hand-shake costs effectively becomes much cheaper as computers get faster, whereas encrypting the connection itself will stay at a constant cost, assuming bandwidth (and thus the amount of data) and processor speed increase at the same rate. Luckily symmetric encryption is already very fast, especially on processors with specialized AES instructions. Generating dynamic webpages is typically more expensive than encrypting them afterwards.

share|improve this answer
    
Correction: for symmetric crypto, SSL originally used RC4 rather than DES or 3DES (although it did have those as an option). RC4 is actually fairly quick, but does have theoretical issues. –  poncho Jul 7 '12 at 21:05

It sounds like you are conflating the strength of SSL and the strength of encryption. The two are distinct; SSL is a protocol that uses encryption, but the security of SSL is not strictly dependent on encryption. SSL can be vulnerable even when the underlying encryption is not.

Overall, security and speed for SSL are not a tit-for-tat trade-off. Making SSL faster can have nothing to do with the actual encryption because SSL is a somewhat bulky protocol layer on top of normal communication streams. The "fast" part of SSL is actually the raw encryption, since encryption algorithms are well-studied for speed of implementation and many high-end servers have hardware support for doing the encryption. The slow part of SSL is everything else.

If you read through the link you posted, you'll note that a lot of the speed issues they're addressing have to do with the overhead that the SSL protocol introduces. They're trying to minimize the number of round-trip TCP exchanges, trying to minimize the data that needs to be sent to start a session, trying to cache keys to avoid re-creating them for returning clients, and so forth. In theory, these these might be doable with no impact on security. (But each tweak must be evaluated on a case-by-case basis.)

Speed and security do have something of a natural trade-off. Any tweak to SSL to make it faster needs to be scrutinized to ensure it doesn't add a security vulnerability. But it isn't just a law of returns, where faster equals less secure and slower equals more secure.

share|improve this answer

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.