Fun with CAKE - Journal of Omnifarious
Feb. 19th, 2006
06:11 pm - Fun with CAKE
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.
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
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