• CakeProtocol2

Goals

• No replays
• No spoofing

• No signatures for data, sender must be able to deny sending ala OTR, but recipient must be confident that the sender sent the data.

• Minimization or elimination of round-trips in many common cases, tolerance of latencies measuring days.

Current ideas

This is my current thinking on how this should all work.

All messages header

All messages begin with these two fields.

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

• sub-protocol - Something identifying whether this is the start of an encrypted session, the continuation of a stored encrypted session, or the start of a pre-session information exchange.

Start of an encrypted session

• destination - CAKE ID of destination

• source - CAKE ID of source

• Time in microseconds (64-bits exactly) must never be repeated
• DH parameter

• Signature - Source signed <destination || source || time || DH parameter>

• HMAC <protocol || sub-protocl || destination || source || time || DH Parameter || Signature> - using HMAC key derived from DH parameter.

• Repeated messages

Continuation of a stored encrypted session

If the recipient is not the destination, or doesn't have the given session id associated with the source, it's expected to send back an indication of this fact either using a saved session it has associated with the source, or creating a new one if necessary, but this is not required. In fact the number of these sent back should be limited as the case should be rare, and this mechanism should not be able to easily be used for a DoS attack.

• source - CAKE ID of source

• destination - CAKE ID of destination

• session id - agreed on when session was stored
• starting byte

• encrypted HMAC <protocol || sub-protocol || source || destination || session id || starting byte> - basically early proof that the initiator knows the original HMAC and encrypted key - Also note that this counts against the number of encrypted bytes in the data stream, and so the starting byte of the following repeated messages must be greater than the starting byte just given by the size of the HMAC.

• Repeated messages

pre-session information exchange

This message is sent if a source has no idea about a destination, except a location. It is used to request that information from a destination.

• source - CAKE ID of source

• destination - CAKE ID if destination

• Time in microseconds - 64-bit value, may never be reused.
• number of assertions - Must be at least 2 since the public key of the source, and the source DH parameter requirements assertion is required. A location assertion is recommended.
• assertion list (number of assertions repeats of the following two fields)
  • length
  • assertion (includes a signature)

• Signature <protocol || sub-protocol || source || destination || number of assertions || all assertion list entries> - Prevent intermediaries from touching the message, as well as a further indication of liveness on the part of the source

Repeated messages (sub-message reused by several previous messages)

This is used in several places.

• Starting byte of message in message stream (only counting encrypted message contents)
• Length of encrypted data (including the HMAC)
• encrypted message contents

  • NOTE the boundaries of these contained messages have absolutely no relation whatsoever to the boundaries where the HMAC is computed in the container. In fact, it's encouraged for the boundaries to be different (if possible) to confuse attackers that are trying to gain information from the message by looking at message lengths.

  • Capability ID - 0 is always 'session control', and 1 is always 'chaff' and is ignored. The rest are session specific and negotiated.
  • message bytes

• encrypted HMAC <starting byte || length || decrypted message contents>

The starting byte of a message can always be computed by simply adding together all the message lengths of the previous messages, which includes all the encrypted bytes and only the encrypted bytes. This is so the starting byte can be easily used with a CTR mode symmetric block cipher.

Design Thoughts

Here is rough sketch of what a session will have to track:

Previous information

This is no longer valid, and is simply saved for easy scavenging later.

• 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 2⁷⁶ 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.