Does frequent key change weaken encryption?

Question

Following scenario: We are using OTR for communication between Alice and Bob which means after each successfull message exchange a re-keying happens for both parties leading to new AES-keys for the encryption and MAC generation.

Lets say Alice and Bob exchange 1000 message-pairs which leads to 1000 re-keying occurrences.

An attacker Mallory is able to record all messages between Alice and Bob.

Mallory brute-forces her way through the encryption by choosing one possible encryption key and trying it for every single one of the 1000 message-pairs. Doesn't this lead to giving Mallory a better chance of cracking the code of one message-pair because she can use a single key and try this key for 1000 message-pairs (thus weakening the encryption)?

A little further thinking: Using a single encryption key over a long period might increase the possibility of exposure of the encryption key. So re-keying is an effective means against that. But comming from the above example, re-keying too often might also lead to a weak encryption. Is there a trade-off between the two of them?

I am not a crypto-analyst or any expert and I am well aware that my language propably doesn't fit into the crypto world by means of being to broad in some statements or not specific enough. I have no problem in understanding probility theory if an answer needs to include it, although I prefer pragmatism over theory.

Answer 1

Strictly speaking, it does make a brute-force attack more likely to recover a key for any message pair, but the impact of recovering a single key is minimized by frequent re-keying, since that key can't aid the adversary in decrypting any other messages. If you don't re-key, a brute force attack is only marginally more difficult but success gives you everything instead of just one message.

Answer 2

OTR uses 128 bit AES-CTR. There is a risk that the same AES key will be generated more than once, but if significantly less than $2^{32}$ messages are ever exchanged between any pair of peers, this risk might be safely considered to be negligible.

However, if a pair of peers exchange more messages than $2^{32}$ and depending on how the implementation selects CTR values, a key collision might occur, and would in such case cause loss of confidentiality for a single message.

I am not aware of any general attack against OTR that compromises integrity, authenticity or forward or future secrecy (with non-negligible probability of success).

Answer 3

This is an example of an attack in a multi-key setting.

Since the objective is that all communications remain secret, rekeying does reduce the effective security. In the case of only a thousand keys this is not very severe, since it only amounts to about a 10-bit loss: 118-bit security is still large enough by a clear margin.

However, if you had a million user-pairs each exchanging a million messages with different keys, an attack with reasonably realistic resources would no longer necessarily have a negligible probability of success.

This is one reason some people suggest 256-bit keys (pdf) even in a classical setting.

In practice the attack cost is not quite that simple. Unless every message has a known cipher input (like zero nonce in CTR mode), you cannot use a single AES computation to check against every key.

Answer 4

well simply said true, with more key changes she can bruteforce the same keys over more messages which may give her faster results but when one key actually has hit, it is just valid for one part of the message and not everything.

Essentially a one-time-pad uses a different key for every message which is the whole point of it. because key re-usage makes the key weaker especially if the algorhythm is bad. that's also a reason why HTTPS connections always determine a key at random for each connection so that the key cannot be used for anything else, which is the main point, one known key means little (or at least not as much as knowing a "master key" for all messages).

With a one-time pad you could essentially use XOR or similar and be safe because the key is not just different for every message but the key itself is long enough to cover it all. Essentially OTP encrypts each bit with a different bit (when used with XOR) which is essentially the epitome of changing keys quickly. Also when there is no way (unless you use a checksum) to find out whether the encryption was a good result or not (I mean when you encrypt hello, there can be a lot of other "logical" decryption results), there's practially no way to see whether a key was correct in the first place, at least by a machine this gets even worse (from the attackers perspective) when the message output per key is lower.

but because one-time pads are pretty inconventient in real life (key exchange) usually we use strong encryption like AES and changing keys.

The Greatest Problem with quickly changing keys is similar with the one-time pad, the key exchange. if Somebody could get into the key exchange then all your futurre keys might be corrupted because the key has to be exchanged somehow. a deterministic key based from an out-of-band generated secret might work pretty well.

I hope that helps, even though it is more general than about OTR specifically.

Answer 5

OTR is trying to achieve the same unbreakability of OTPs by changing keys.

The unbreakable part of OTPs comes from the following: Consider if the one-time pad is used to encode the word "otter." If an attacker tries to brute force the contents of the pad, the message will "decrypt" into every possible combination of 6 characters (e.g.: "lemur." "badger" etc..) Since the pad is truly random there are no statistical methods that the attacker can hope to use to infer which combination is correct. (link: http://www.ranum.com/security/computer_security/papers/otp-faq/ )

This means an attacker can guess an encryption key and try it for all 1000 cipher-messages. If he gets lucky and decrypts a cipher-message, he can't be sure that the decrypted message is the actual message being sent. His key might just be the wrong key decrypting the cipher-message into something that makes sense but is not the actual message sent from Alice to Bob.

So even if as many messages have been sent between Alice and Bob as there are 128Bit-keys available, one key might as well decrypt more than one message-pair into something that makes sense. Thus an attacker can't be sure whether an encryption key he used is the actual one or just happens to be a wrong one.

One thing that helps an attacker to know whether his encryption key might be the right one is if he knew that there happens to be a pattern within the encrypted messages (i.e. message-header-fields, payload, trailer).