This is version 1 of the AEAD example protocol.
This protocol transmits any number of authenticated plaintext data and any number of encrypted messages. It authenticates them with any positive number of keys, which in most use cases will be one.
Several of the operations may be either untransmitted, transmitted without framing information, or
transmitted with framing information. These are written as meta-AD/CLR and AD/CLR
operations. The protocol is secure with any combination of transmitted and untransmitted information
in any order. If the recipient uses a different combination of transmitting and not transmitting, then
the message will fail to decrypt correctly (that is, the MAC check will fail with high probability).
The domain separation string for this protocol is "https://strobe.sourceforge.io/examples/aead".
The protocol consists of the following operations:
KEY operations, with the SYM_KEY = 0x01 tag: (meta-AD(0x01); KEY(key))+
VERSION operations, with the VERSION = 0x21 tag and exactly 2 length bytes. This protocol specification is version 0x01:
(meta-AD/CLR(0x21 0x01 0x00); AD/CLR(0x01))+
NONCE operations, with the NONCE = 0x04 tag and any number of length bytes.
Also, zero or more AUTH_DATA operations, with the AUTH_DATA = 0x05 tag and any number of length bytes. The AUTH_DATA operations may be mixed in arbitrary order with the nonce(s): ( meta-AD/CLR(0x05 .. length); AD/CLR(ad) | meta-AD/CLR(0x04 .. length); AD/CLR(nonce) )*If the metadata for an AD or nonce is transmitted, then the AD or nonce must also be transmitted.
APP_CIPHERTEXT operations, with the APP_CIPHERTEXT = 0x03 tag and any number of length bytes: (meta-AD/CLR(0x03 .. length); ENC(data))*
MAC operation, with the MAC = 0x06 tag and exactly 2 length bytes:
meta-AD/CLR(0x06, length low, length high); MAC()The MAC must be at least 8 bytes (64 bits) long, but 128 bytes is recommended.
The capacity of the sponge must be at least 2λ bits, where λ is the desired security level. For 128-bit security, the capacity must be 32 bytes (256 bits) or more.
The keys must be drawn from a set which is hard to guess. We recommend one key which is uniformly random and 32 bytes (256 bits) long, but 16 bytes (128 bits) is acceptable for most use cases. The keys must be kept secret from the adversary. If the adversary can guess the keys, then all security will be lost.
The (keys,version,nonces,auth_datas) tuple must be unique. Otherwise, an adversary can learn the encrypted messages, but still can't forge MACs. This construction is not nonce-misuse resistant.
If the security requirements are observed, then the system is IND-CCA2 secure. This means that an adversary cannot distinguish between encrypted messages that have the same length. The adversary can learn the length of the message. If a tuple of messages is sent, then the adversary can learn the length of the messages if and only if the length framing is sent. Furthermore, the adversary cannot forge MACs, except by random chance (i.e. with probability 256-MAC length).
The adversary can gain an advantage by collecting data (possibly across multiple encrypted messages) and by doing computation. The advantage is ε < (N/2λ)2, where N is the number of times the adversary calls F, plus the number of times someone else calls F and the adversary collects the results.
The adversary can also break all security by guessing the keys, which will happen after N work with probability ND/2K, where D is the number of encrypted messages with different keys but the same (nonces,ADs) that the adversary can collect, and K is the min-entorpy of the key space.
This protocol may be composed before or after any number of other protocols, using an operation
meta-AD/CLR(0x00 .. length); AD/CLR(sep), where sep is the domain separation string
"https://strobe.sourceforge.io/examples/aead".
Larger protocols may instead assign other (e.g., shorter) separation strings, or omit them
if the use of this protocol is clear from context.
When running a second instance of this protocol following the first, this operation may be omitted.
If a previous protocol has set one or more keys, then the KEY component of this may be omitted.
It will then rely on the security of the previously-set keys.
If in a previous protocol, this party has sent messages (or absorbed AD) which it knows is unique, then this satisfies the (keys,version,nonces,auth_datas) uniqueness requirement. Messages sent by the other party also satisfy this. But because it is often hard to tell if the other party's messages have been replayed, applications SHOULD NOT rely on this.