Skip to content

Instantly share code, notes, and snippets.

@chris-gc
Last active August 29, 2015 13:56
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save chris-gc/9194660 to your computer and use it in GitHub Desktop.
Save chris-gc/9194660 to your computer and use it in GitHub Desktop.
PFS Key Ratchet
And I have a design specced out for adding PFS to Calico without
adding any overhead:
The problem is that right now Calico never rekeys. So long encrypted
communications, if one side is compromised, can be decrypted from the
start. To allow for future secrecy, rekeying will be added controlled
by the client automatically on a timer.
Right now I'm using 24 bits for the IV. This is actually pretty excessive.
But 16 bits is not enough.
So I can steal a bit from the IV to act as a key ratchet flag.
The flag can be controlled by the client. If he wants to flip the key to
H(K), then he can set the key ratchet flag to 1. The server, some time
later, can also select to flip the key to H(K) by setting the same bit in
the other direction. After the client receives a flipped bit in response
from the server, and it has been X seconds since it received a non-flipped
bit, then the client will ratchet the key permanently.
Once the client flip the key ratchet bit, the server will similarly wait X
seconds before ratcheting his key permanently since the last unflipped bit.
The client is prevented from ratcheting faster than 2X seconds.
The other concern is how to include the bit in the MAC. I'm planning on
XORing in the ratchet bit as a 64-bit all-ones mask into the high half of
the SipHash MAC key. This doesn't cause any collisions in the MAC key.
This scheme can be run entirely within the Calico codebase without
changing the API nor adding any new overhead. The user doesn't even
need to know it's happening.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment