Transport layer key rotation race condition #633
I'm reimplementing the transport layer once again in python to allow us to write a better test-suite, and while implementing the key rotation I noticed something strange: there might be a race-condition in how we rotate keys. The current specification states this:
Notice that we are managing 4 keys in total:
Assume that both nodes have sent and received 499 messages (
Notice however that there is a crossover in the rotation, sending the first message that triggered the sending key to rotate modified the chaining key
The following illustrates how the keys change during this example:
At this point none of the keys match up anymore, making decryption impossible, and all because we have asynchronous updates to the chaining key.
This is unlikely to be very severe since we first need to get into a situation in which we rotate at the same time, but it is annoying, especially since decryption will fail only on the next (501st) message.
Can someone confirm my suspicion?