?

Log in

No account? Create an account

Fun with CAKE - Journal of Omnifarious

Feb. 19th, 2006

06:11 pm - Fun with CAKE

Previous Entry Share Next Entry

So, I've been thinking about some stuff. First, I've had a really hard time designing a protocol that lives on top of CAKE. A lot of this is because it was hard to figure out how replies should work. Second, OTR has some really interesting features that I would like for CAKE to have. So, I'm redoing the protocol.

Of course, under normal circumstances redoing a protocol is a huge pain. But CAKE has the marvelous advantage of having no users. ;-)

Anyway, if you're interested, I'd appreciate comments and questions. Also, you can go fiddle with the wiki. The wiki page with the information behind the cut is at CakeProtocol2.

CakeProtocol2

Goals

  • No replays

  • No spoofing

  • Minimal sessions

Fields

  • protocol - The main version #, 2 in this case

  • sub-proto - Something identifying this as a unicast datagram

  • destination - ?CAKE ID of destination

  • source - ?CAKE ID of source

  • message id - Consisting of the subfields 'session' and 'sequence'

  • (Only if sequence is 0) crypto data - encrypted and signed block cipher key and MAC key

  • service - The service this message is destined for

  • message parts - all parts of flag 0 until the very last part which has a flag 1 - The total length of all the parts must not exceeed 276 bytes.

    • end flag - 0 if this is a data part, 1 for the MAC block at the end.

      • For a flag of 0

        • length

        • encrypted body

      • For a flag of 1

        • encrypted 256 bit MAC block for the concatenation of all the decrypted message bodies plus the header.

Session IDs, sequence numbers and Message IDs

A session represents a particular block cipher key and MAC key.

It's suggested that sessions be remembered for at least 5 seconds, but it is not required.

All sessions start with sequence # 0. Messages with a sequence # of 0 MUST contain a block cipher key and a MAC key signed by the source encrypted to the destination that the destination can retrieve and verify with no further messages exchanged with the source (provided that it already knows the source's full public key).

Handling of message IDs

A message id is considered a globally unique identifier for a message from the source to the destination. As such, there is some processing that should occur to ensure this rule is properly maintained.

A message id taken as a whole is a monotonically increasing number. This means that you can base a sliding window on the message id and toss out messages that are too 'old' to fit in the window. This greatly simplifies protection against replay attacks as you only have to remember the specific message ids you've recieved within the window.

Use of protocol data in higher layer protocols

The service receiving the message knows the source, the destination, and the message id. It should not worry about the internal structure of the message id. It may use these fields in its messages and reference previously seen messages by their message id.

In particular, when acknowledging reciept of data, reference to the message id being acknowledged is encouraged.

last edited 2006-02-19 17:59:29 by EricHopper

Current Mood: [mood icon] contemplative