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
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
The protocol consists of the following operations:
KEYoperations, with the
SYM_KEY = 0x01tag:
VERSIONoperations, with the
VERSION = 0x21tag and exactly 2 length bytes. This protocol specification is version 0x01:
(meta-AD/CLR(0x21 0x01 0x00); AD/CLR(0x01))+
NONCEoperations, with the
NONCE = 0x04tag and any number of length bytes. Also, zero or more
AUTH_DATAoperations, with the
AUTH_DATA = 0x05tag and any number of length bytes. The
AUTH_DATAoperations 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_CIPHERTEXToperations, with the
APP_CIPHERTEXT = 0x03tag and any number of length bytes:
(meta-AD/CLR(0x03 .. length); ENC(data))*
MACoperation, with the
MAC = 0x06tag 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.