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.
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.
The message number part of these messages is like a TCP port number. It identifies the application layer protocol the messages are intended for. It is unencrypted because I think people and organizations should be able to filter messages that go through their networks by what their intended purpose is.
This will be a simple list of fields in the message with repeating sections marked. After the message is layed out, a list of the fields (including some fields from the common CAKE message header) that are included in the MAC and the signature, along with whether the decrypted version of the field is used, or the field as it appears in the message is used.
| Field name | Short name | Basic field type |
| Parts common to all CAKE messages | ||
| See The CAKE Message Layout | ||
| Message family 000 header | ||
| Source key name | srcname | key name |
| Destination key name | destname | key name |
| Source cookie | srccookie | fixed length: 6 octets |
| Destination cookie | destcookie | fixed length: 6 octets |
| Encryption header | enchdr | variable length string |
| Message data chunk (repeated)
Message data appears in chunks. Only the last chunk may be less than 1000 octets long. The MAC of the first chunk includes the header information. The MACs of the remaining chunks only include the length field for that chunk, and the unencrypted chunk data. This is resistant to chunk reordering because decrypting the chunk (and its MAC) will result in gibberish if its order is different from where it was in the original message. |
||
| Encrypted message data The length is unencrypted, but the message data is encrypted. |
encmsgn | variable length string |
| Encrypted MAC Using HMAC |
encmacn | fixed length: 32 octets |
| Signature | ||
| Signature data | signature | variable length string |
All of these fields are signed as they appear in the message. This is so that someone other than the final recipient (who is the only person who can easily decrypt the message) can verify the signature. Again, this is so firewalls can be built that do something useful with encrypted traffic.
Some of these fields come from the common CAKE message header.
The signature only verifies that the message came from the key identified by the srcname field. The MAC verifies that the message was originally encrypted by the key identified by the srcname field.
If the MAC were not there, Alice could send Bob an encrypted message, and Mallory would be able to pick it up, put his own name on it, and send it to Bob claiming it was his. This would allow Mallory to send Bob the same message as Alice did, even if Mallory couldn't really tell what the message said.
Also, since the encryption is CTR mode, Mallory could even intercept a message from Alice to Bob, flip a few bits (that would be then also be flipped in the decrypted message) and send to Bob claiming that it came from him. This is even worse than the first attack, and the MAC protects against this as well.
In order to prevent the first scenario, the set of MACed fields must include the srcname field from the header. That field isn't part of the encrypted portion of the message. Since the MAC must already include some header fields, I decided to include all of them, both for simplicity, and to protect against attacks I haven't yet thought of.
Some of these fields are used in the form they appear in the message when it is travelling between Alice and Bob. Others are used in only in their unencrypted forms, the forms that hopefully only Alice and Bob can see. If the field is of the latter variety, it's name will have a 'D ' in front of it to indicate that it's decrypted form is to be used.
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.
| Field name | Short name | Basic field type |
| Parts common to all CAKE messages | ||
| See The CAKE Message Layout | ||
| Message family 000 header | ||
| Source key name | srcname | key name |
| Destination key name | destname | key name |
| Source cookie | srccookie | fixed length: 6 octets |
| Destination cookie | destcookie | fixed length: 6 octets |
| Message data chunk (repeated)
Message data appears in chunks. Only the last chunk may be less than 1000 octets long. |
||
| Message data The length is unencrypted, but the message data is encrypted. |
encmsgn | variable length string |
| Signature | ||
| Signature data | signature | variable length string |
Some of these fields come from the common CAKE message header.