Server to server encryption: Key rotation over the air. Can it improve security?

Question

In my other question, I explored whether to write my own encryption or use an existing one. I was advised to use TLS or AES or something that is established.

This question is about key rotation. It seems that given enough resources, an eavesdropper might could decrypt information, but by the time he arrived at the decrypted product, it would be pretty old. But then he has the key.

The obvious mitigation against that is to change the keys periodically, but it may not be practical to physically bring data to the location to create the new key.

However, if the data was constantly acting as adjustments to the key, or if there were periodic fresh keys sent through the encrypted connection, the attacker would likely have to store lots of data before he finished decryption, then would have to re-play that data to arrive at up-to-date information.

What are your thoughts on this, And are there encryption routines already out there that use either data adjusting the key or automatic fresh key transmission?

Answer 1

With a proper TLS-with-AES session, the time needed for an eavesdropper to "decrypt information" would range in centuries, at least if the "enough resources" are limited to, say, converting the whole mass of Jupiter into energy. At that time I am pretty sure that the involved computers will have turned into a compact mass of rust, so the point is kinda moot. In a nutshell, symmetric encryption is not the weak point of TLS; arguably, properly used encryption has not been the weak point of anything in the last two decades (at least).

Nevertheless, for the truly paranoid who wants to get a warm fuzzy feeling of safety out of ritual cryptographic incantations, you can just negotiate a new handshake over an existing session, at any time you want. Both client and server can initiate that. See the TLS standard, especially sections 7.4.1.1 and 7.4.1.2.

Answer 2

Thomas has it dead on for TLS and/or AES.

If you're working with a less modern algorithm or you're extra paranoid, both of the key refresh methods you mention have been tried at various points in time and they both have drawbacks:

• data as seed to new key - this is the basis for some stream ciphers - for example see Cipher Feedback and Output Feedback modes commonly used with DES. The trick is - that the receiver needs to stay in sync with the sender. If there is a gap in the transmission, the transmission can quickly turn into gibberish if the wrong key is applied to the encrypted data.

• wrap new key in old key - this one is rarely used, since if you are assuming the attacker (given time) has gotten your key, then you have to assume that he'll have captured all your cipher text and he will not have a problem getting the new key. Mostly, at that point, you've saved him the work of figuring out the new key.

A typical solution to this problem is to use a secondary key for transmitting the symmetric key. That's exactly what TLS does - it uses an asymmetric key to protect the distribution of the symmetric key. That adds extra burden - to get that transmission, the attacker must figure out the private key of the asymmetric pair used for the symmetric key transmission. There won't be much exposure here, as they only thing that may be encrypted is new session (symmetric) key pairs.

Another one - in systems which can't handle asymmetric keys, is to use a secondary key distribution key that is ONLY used for key distribution. This will have a shelf life, since that key will have exposure problems, too, but it mitigates the risk on some level.

Key distribution is one of the nastier problems of cryptography. No matter how you slice it, you have to get at least the first key out there in a somewhat painful fashion. Then you need a way to keep keys appropriately fresh, and you need a way to recover if a key is ever lost or compromised. The techniques for all that vary greatly depending on whether you are talking about asymmetric or symmetric cryptography, and some of the best systems mix the two for greatest potency.

Answer 3

I hate answers I'm about to give but in this instance it holds true. If you have to ask if to use a pre-existing crypto library or try to create your own, you definitely already have your answer. Even still, creating something like AES or Skein or something similar is best left as an exercise for learning and not production. Maybe I misread your intent, but don't try to create your own crypto for anything less than something fun for yourself.

Though, to answer your question, the point of the strength of encryption is to use appropriately strong crypto to ensure the confidentiality of the data for as long as it is useful. If by using today's computing power you are transmitting data that needs to be kept confidential for 9 years, but it'll take 100 years to break the encryption, I think you're probably good without rotating the keys.

I ask what would be a good reason to introduce added complexity, for no benefit. Sounds like you're asking for a late night troubleshooting some cryptic error trying to retrieve some critical information.