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:

- One or more
`KEY`

operations, with the`SYM_KEY = 0x01`

tag:(meta-AD(0x01); KEY(key))+

- Zero or more
`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))+

- Zero or more
`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. - Zero or more
`APP_CIPHERTEXT`

operations, with the`APP_CIPHERTEXT = 0x03`

tag and any number of length bytes:(meta-AD/CLR(0x03 .. length); ENC(data))*

- Exactly one
`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 `N``D`/2^{K}, 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(, wheresep)

`"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.