Archive encrypted traffic, for later decryption attempts?

Question

I am concerned about sending long-term sensitive information over SSL. Someone who does not have the private key could record SSL traffic (with WireShark, Fiddler or some such) and store it for several years. They would not be able to decrypt the traffic now. But later, when attacks against SSL have progressed, or when computers have become faster, they might decrypt the traffic that they have recorded.

As I understood of Google they are into temporary SSL because of such reason (the topic). Is this reality or just a way for companies to sell, by the name of security?

I may state something wrong or nearly wrong here, because i'm not super-familiar on the context. I'm glad of help if I misunderstood something or if there are details that worth extra explanation.

This of course also apply to traffic that are compromised with XSS or other ways with similiar result (listen on someones traffic).

As Google stated in their reasons, within 10 years the computers will be strong enough to decrypt this traffic. I'm sorry I do not have a link to an English news page on this topic. Does this mean that our traffic can be listened on today and be archived? Then when the time is right, the data is decrypted by brute force, even if the eavesdropper has not been able to obtain the private key?

Do we need to care? When and how? May it apply to other situations then just http traffic, where data are transferred encrypted with a very high trust (by human)?

Answer 1

Nice question.

I'd say we can only worry, but not do much. We can secure our data by today's standards, but tomorrow might change the whole ballgame. If quantum computers really can brute-force ciphertexts at a speed magnitudes higher than what we can do now, than a 128-bit block cipher could suddenly be peanuts. But what can you do about it?

Perhaps you should not digitally transmit information that will still be sensitive/harmful in 10 years time...

Answer 2

I think you are being overly worried. If you choose appropriate ciphersuites for SSL, then the cryptography is unlikely to be the weakest link. If you control the server, you can control what ciphersuites will be used and what key lengths will be used. Thus, if you configure things appropriately, for most purposes this will be plenty good enough.

You might consider using "ephemeral Diffie-Hellman". The idea is that each SSL connection will generate a new private/public keypair, to use in setting up the secure channel, then delete this keypair afterwards. This has some modest benefits: if your server is broken into and someone steals the private keys on your server, the key material will not of any help in decrypting SSL traffic that may have been intercepted previously. The primary disadvantage of ephemeral Diffie-Hellman is that it introduces some performance overhead.

For instance, the following line in your Apache configuration will restrict it to ciphersuites believed to be strong:

SSLCipherSuite AES:!ADH

Even better is to restrict to ephemeral Diffie-Hellman ciphersuites, which you could do by using the following line:

SSLCipherSuite kEDH+AES:!ADH

When you generate your private key on the server, I also recommend that you choose a large key length. A 4096-bit key is probably overkill, but one you could use if you are very concerned. A 2048-bit key is almost certainly adequate.

With these precautions, someone who intercepts your traffic and stores it for several years is not going to be able to break your traffic, given our current understanding of technology. It would require a major breakthrough to break such traffic. This is most likely still true even if we posit that the attacker is willing to wait several decades. Further out -- say, 50-100 years out -- I doubt anyone can predict what may be possible.

Answer 3

If you have such valuable information that people might record your ssl traffic for decryption in futur, I bet they are trying to get their hands on it in more direct ways right now, and chances are they would be more successful by direct means, and sooner.

Answer 4

Anyone who can obtain ciphertext being transmitted could also potentially archive it for as long as they want, spend as much resources as they want on trying to decipher the information, and do so whenever they want - which could be at a time when technology advances have made such deciphering "trivial".

There is no way to fully protect against this scenario which comes to mind except physically securing a communication channel against eavesdropping or using ciphers which can never be "broken" such as one-time pads with truly random data.

Then again this is not a free lunch for an attacker. They will need to spend resources capturing ciphertext and spend additional resources archiving the information for possibly a very long time. Unless the expected pay-off of deciphering the information (in the excpected timeframe before the information can be deciphered) exceeds the costs of deciphering the information, it is not worth the effort for an attacker.

Answer 5

I would suggest you don't transmit the information or be sure to transmit it in a more secure channel like PGP/GPG with a High Security setting.(RSA-2048 or RSA-4096 for instance, which should remain secure for 50 and 100 years accordingly; supposing Quantum Computing doesn't get out by then.)

Good luck with whatever you have to hide and remember you can't hide secrets from the future with math.

Answer 6

Usage of security is always a trade-off. Perfect security cannot be achieved. The only secret that is well kept is one who is solely known by one individual. If you materialise this secret to communicate it, it is subject to being intercepted. So the means you use to protect it need to be chosen carefully and accordingly to the time of validity of the secret.

Of course you can store informations to decode it at later time. Technical progress, research breakthrough made this possible. But what is the point of changing password? This is not for you to have hard time remembering it, but to counter the potential theft of it. Besides, if someone intercepts the hash, you want your policy to force you to change it before the minimum time it will take for the attacker to break the code. If I use a Vigenere code to transmit a token to a friend, it may be sufficient if it takes less time for my friend to consume the token than the attacker to break the code. Or Vigenere is considered unsafe. The notion of "safety" is not absolute.

As Chris said, maybe information that remains sensitive for more than a certain time should not be transmitted over the internet.