Code Poetry
and Text Adventures

by catid posted (>30 days ago) 1:18pm Mon. Feb 24th 2014 PST
I revised Calico again this weekend: https://github.com/catid/calico.

It now refers to itself as an AEAD and uses more of the right words for things, as well as switching to SipHash for MAC, which is somewhat faster for small/medium sized packets as well as being simpler.  I added more unit tests and checked my SipHash against the test vectors for SipHash to make sure it was solid.  I also stumbled a bit implementing SipHash as a MAC because initially it did not include the IV.  Without adding the IV into the MAC tag, it is easy to just replay past messages.  There is now a unit test to verify that you cannot do that with Calico in the tester.

Future work: Adding forward secrecy

The last thing I want to change in Calico is its lack of forward secrecy.  It doesn't periodically rekey and erase the old key.  So if at some point a long-running connection is compromised, then it can be decrypted back to the first message.

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 seems pretty slick.  It 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.  During rekeying no packets are lost.
last edit by catid edited (>30 days ago) 5:24pm Mon. Feb 24th 2014 PST