Single destination, non-session messages

These messages are the workhorse of CAKE. The basic model is a non-multicast IP packet. Delivery isn't necessarily reliable, though over some transports (like SMTP) it is expected that delivery is reliable.

All messages in this family are signed by their source key, and they are usually encrypted to their destination key.

The message number part of these messages is like a TCP port number. It identifies the protocol the messages are intended for. It is external to the message because I think people and organizations should be able to filter messages by what their intended purpose is.

The message number part of these messages also has some structure. The last bit (bit 4 in the full message number) is the 'application specific' bit. All messages that are in some registered protocol will have a 0 in this bit.

Messages that have the application specific flag set have a protocol specifier with no globally specified meaning. Application writers are encouraged do some work to ensure that their numbers don't overlap with others, but it's not a disaster if they do.

There are two main subtypes of message inherited from the global message subtypes, encrypted and unencrypted. Unencrypted messages are still signed and are still addressed to a public key.

This will get rather complicated as parts of the message are covered by the signature, parts are covered by the MAC, parts are MACed in the form they appear in in the message, and parts are MACed in their unencrypted form.

In the interests of clarity, I've layed out the fields of a message in the following table. There is a column flagging parts that are signed with a 'M', or a 'D' meaning that the form that appears in the message is signed, or the unencrypted form is signed. There is a column flagging parts that are MACed in a similar way.

If you notice, all signed data is as it appears in the message. This is so that someone other than the final recipient can verify the signature. Again, this is so firewalls can be built that do something useful with encrypted traffic.

The MAC is there to prevent someone from slicing apart the encrypted message and putting it back together again with their own key as the sender and signing it. This would be accepted as a valid message. This is possible because the signature signs the data as it appears in the message, so the fact the message is encrypted doesn't prevent a third party from creating a valid signature.

This seemed an undesireable property. If Alice sends Bob an encrypted message, Walter shouldn't be able to send Bob the exact same encrypted message, even if Walter can't read it. So, an internal, encrypted MAC was added that included the header fields of the message so the message could be separately verified after decryption in a way not susceptible to this kind of tampering.

This is pretty simple, and simply drops a few fields from the encrypted variant that are used for encryption. It also drops the MAC.

The MAC is dropped because the problem the MAC is meant to prevent is pointless if the message is unencrypted. Walter could easily read the message Alice is sending Bob and send it himself.

In the interests of clarity, I've layed out the fields of a message in the following table. There is a column flagging parts that are signed.