]>
The AEGIS Family of Authenticated Encryption Algorithms
Fastly Inc.
fde@00f.net
Individual Contributor
fabio@esse.ch
Individual Contributor
samuellucas6@pm.me
Crypto Forum
InternetDraft
This document describes AEGIS128L and AEGIS256, two AESbased authenticated encryption algorithms designed for highperformance applications.
This document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard.
Discussion Venues
Source for this draft and an issue tracker can be found at
.
Introduction
This document describes the AEGIS128L and AEGIS256 authenticated encryption with associated data (AEAD) algorithms , which were chosen as additional finalists for highperformance applications in the Competition for Authenticated Encryption: Security, Applicability, and Robustness (CAESAR). Whilst AEGIS128 was selected as a winner for this use case, AEGIS128L has a better security margin alongside improved performance and AEGIS256 uses a 256bit key . All variants of AEGIS are constructed from the AES encryption round function . This document specifies:
 AEGIS128L, which has a 128bit key, a 128bit nonce, a 1024bit state, a 128 or 256bit authentication tag, and processes 256bit input blocks.
 AEGIS256, which has a 256bit key, a 256bit nonce, a 768bit state, a 128 or 256bit authentication tag, and processes 128bit input blocks.
The AEGIS cipher family offers performance that significantly exceeds that of AESGCM with hardware support for parallelizable AES block encryption . Similarly, software implementations can also be faster, although to a lesser extent.
Unlike with AESGCM, nonces can be safely chosen at random with no practical limit when using AEGIS256. AEGIS128L also allows for more messages to be safely encrypted when using random nonces.
With some existing AEAD schemes, such as AESGCM, an attacker can generate a ciphertext that successfully decrypts under multiple different keys (a partitioning oracle attack) . This ability to craft a (ciphertext, authentication tag) pair that verifies under multiple keys significantly reduces the number of required interactions with the oracle in order to perform an exhaustive search, making it practical if the key space is small. For example, with passwordbased encryption, an attacker can guess a large number of passwords at a time by recursively submitting such a ciphertext to an oracle, which speeds up a password search by reducing it to a binary search.
In a fully committing AEAD scheme, finding different inputs (key, nonce, associated data, message) producing the same authentication tag has a complexity that depends on the tag size. A 128bit tag provides 64bit committing security, which is generally acceptable for interactive protocols. With a 256bit tag, finding a collision becomes impractical. As of the time of writing, no research has been published claiming that AEGIS is not a fully committing AEAD scheme.
Finally, unlike most other AESbased AEAD constructions, leaking a state does not leak the previous states.
Note that an earlier version of Hongjun Wu and Bart Preneel’s paper introducing AEGIS specified AEGIS128L and AEGIS256 sporting differences with regards to the computation of the authentication tag and the number of rounds in Finalize() respectively. We follow the specification of that is current at the time of writing, which can be found in the References section of this document.
Conventions and Definitions
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”, and “OPTIONAL” in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.
Primitives:

x: the length of x in bits.

a ^ b: the bitwise exclusive OR operation between a and b.

a & b: the bitwise AND operation between a and b.

a  b: the concatenation of a and b.

a mod b: the remainder of the Euclidean division between a as the dividend and b as the divisor.

LE64(x): the littleendian encoding of unsigned 64bit integer x.

ZeroPad(x, n): padding operation. Trailing zeros are concatenated to x until the total length is a multiple of n bits.

Truncate(x, n): truncation operation. The first n bits of x are kept.

Split(x, n): splitting operation. x is split into nbit blocks, ignoring partial blocks.

Tail(x, n): returns the last n bits of x.

AESRound(in, rk): a single round of the AES encryption round function, which is the composition of the SubBytes, ShiftRows, MixColums and AddRoundKey transformations, as defined in section 5 of . Here, in is the 128bit AES input state, and rk is the 128bit round key.

Repeat(n, F): n sequential evaluations of the function F.

CtEq(a, b): compares a and b in constanttime, returning True for an exact match, False otherwise.
AEGIS internal functions:

Update(M0, M1): the state update function.

Init(key, nonce): the initialization function.

Absorb(ai): the input block absorption function.

Enc(xi): the input block encryption function.

Dec(ci): the input block decryption function.

DecPartial(cn): the input block decryption function for the last ciphertext bits when they do not fill an entire block.

Finalize(ad_len_bits, msg_len_bits): the authentication tag generation function.
Input blocks are 256 bits for AEGIS128L and 128 bits for AEGIS256.
AES blocks:

Si: the ith AES block of the current state.

S'i: the ith AES block of the next state.

{Si, ...Sj}: the vector of the ith AES block of the current state to the jth block of the current state.

C0: an AES block built from the following bytes in hexadecimal format: { 0x00, 0x01, 0x01, 0x02, 0x03, 0x05, 0x08, 0x0d, 0x15, 0x22, 0x37, 0x59, 0x90, 0xe9, 0x79, 0x62 }.

C1: an AES block built from the following bytes in hexadecimal format: { 0xdb, 0x3d, 0x18, 0x55, 0x6d, 0xc2, 0x2f, 0xf1, 0x20, 0x11, 0x31, 0x42, 0x73, 0xb5, 0x28, 0xdd }.
AES blocks are always 128 bits in length.
Input and output values:

key: the encryption key (128 bits for AEGIS128L, 256 bits for AEGIS256).

nonce: the public nonce (128 bits for AEGIS128L, 256 bits for AEGIS256).

ad: the associated data.

msg: the plaintext.

ct: the ciphertext.

tag: the authentication tag (128 or 256 bits).
The AEGIS128L Algorithm
AEGIS128L has a 1024bit state, made of eight 128bit blocks {S0, ...S7}.
The parameters for this algorithm, whose meaning is defined in are:

K_LEN (key length) is 16 octets (128 bits).

P_MAX (maximum length of the plaintext) is 2^{61} octets (2^{64} bits).

A_MAX (maximum length of the associated data) is 2^{61} octets (2^{64} bits).

N_MIN (minimum nonce length) = N_MAX (maximum nonce length) = 16 octets (128 bits).

C_MAX (maximum ciphertext length) = P_MAX + tag length = 2^{61} + 16 or 32 octets (2^{64} + 128 or 256 bits).
Distinct associated data inputs, as described in shall be unambiguously encoded as a single input.
It is up to the application to create a structure in the associated data input if needed.
Authenticated Encryption
The Encrypt function encrypts a message and returns the ciphertext along with an authentication tag that verifies the authenticity of the message and associated data, if provided.
Security:
 For a given key, the nonce MUST NOT be reused under any circumstances; doing so allows an attacker to recover the internal state.
 The key MUST be randomly chosen from a uniform distribution.
Inputs:

msg: the message to be encrypted (length MUST be less than P_MAX).

ad: the associated data to authenticate (length MUST be less than A_MAX).

key: the encryption key.

nonce: the public nonce.
Outputs:

ct: the ciphertext.

tag: the authentication tag.
Steps:
Authenticated Decryption
The Decrypt function decrypts a ciphertext, verifies that the authentication tag is correct, and returns the message on success or an error if tag verification failed.
Security:
 If tag verification fails, the decrypted message and wrong message authentication tag MUST NOT be given as output. The decrypted message MUST be overwritten with zeros.
 The comparison of the input tag with the expected_tag MUST be done in constant time.
Inputs:

ct: the ciphertext to be decrypted (length MUST be less than C_MAX).

tag: the authentication tag.

ad: the associated data to authenticate (length MUST be less than A_MAX).

key: the encryption key.

nonce: the public nonce.
Outputs:
 Either the decrypted message msg or an error indicating that the authentication tag is invalid for the given inputs.
Steps:
The Init Function
The Init function constructs the initial state {S0, ...S7} using the given key and nonce.
Inputs:

key: the encryption key.

nonce: the public nonce.
Defines:

{S0, ...S7}: the initial state.
Steps:
The Update Function
The Update function is the core of the AEGIS128L algorithm.
It updates the state {S0, ...S7} using two 128bit values.
Inputs:

M0: the first 128bit block to be absorbed.

M1: the second 128bit block to be absorbed.
Modifies:
Steps:
The Absorb Function
The Absorb function absorbs a 256bit input block ai into the state {S0, ...S7}.
Inputs:

ai: the 256bit input block.
Steps:
The Enc Function
The Enc function encrypts a 256bit input block xi using the state {S0, ...S7}.
Inputs:

xi: the 256bit input block.
Outputs:

ci: the 256bit encrypted block.
Steps:
The Dec Function
The Dec function decrypts a 256bit input block ci using the state {S0, ...S7}.
Inputs:

ci: the 256bit encrypted block.
Outputs:

xi: the 256bit decrypted block.
Steps:
The DecPartial Function
The DecPartial function decrypts the last ciphertext bits cn using the state {S0, ...S7} when they do not fill an entire block.
Inputs:
Outputs:

xn: the decryption of cn.
Steps:
The Finalize Function
The Finalize function computes a 128 or 256bit tag that authenticates the message and associated data.
Inputs:

ad_len_bits: the length of the associated data in bits.

msg_len_bits: the length of the message in bits.
Outputs:

tag: the authentication tag.
Steps:
The AEGIS256 Algorithm
AEGIS256 has a 768bit state, made of six 128bit blocks {S0, ...S5}.
The parameters for this algorithm, whose meaning is defined in are:

K_LEN (key length) is 32 octets (256 bits).

P_MAX (maximum length of the plaintext) is 2^{61} octets (2^{64} bits).

A_MAX (maximum length of the associated data) is 2^{61} octets (2^{64} bits).

N_MIN (minimum nonce length) = N_MAX (maximum nonce length) = 32 octets (256 bits).

C_MAX (maximum ciphertext length) = P_MAX + tag length = 2^{61} + 16 or 32 octets (2^{64} + 128 or 256 bits).
Distinct associated data inputs, as described in shall be unambiguously encoded as a single input.
It is up to the application to create a structure in the associated data input if needed.
Authenticated Encryption
The Encrypt function encrypts a message and returns the ciphertext along with an authentication tag that verifies the authenticity of the message and associated data, if provided.
Security:
 For a given key, the nonce MUST NOT be reused under any circumstances; doing so allows an attacker to recover the internal state.
 The key MUST be randomly chosen from a uniform distribution.
Inputs:

msg: the message to be encrypted (length MUST be less than P_MAX).

ad: the associated data to authenticate (length MUST be less than A_MAX).

key: the encryption key.

nonce: the public nonce.
Outputs:

ct: the ciphertext.

tag: the authentication tag.
Steps:
Authenticated Decryption
The Decrypt function decrypts a ciphertext, verifies that the authentication tag is correct, and returns the message on success or an error if tag verification failed.
Security:
 If tag verification fails, the decrypted message and wrong message authentication tag MUST NOT be given as output. The decrypted message MUST be overwritten with zeros.
 The comparison of the input tag with the expected_tag MUST be done in constant time.
Inputs:

ct: the ciphertext to be decrypted (length MUST be less than C_MAX).

tag: the authentication tag.

ad: the associated data to authenticate (length MUST be less than A_MAX).

key: the encryption key.

nonce: the public nonce.
Outputs:
 Either the decrypted message msg or an error indicating that the authentication tag is invalid for the given inputs.
Steps:
The Init Function
The Init function constructs the initial state {S0, ...S5} using the given key and nonce.
Inputs:

key: the encryption key.

nonce: the public nonce.
Defines:

{S0, ...S5}: the initial state.
Steps:
The Update Function
The Update function is the core of the AEGIS256 algorithm.
It updates the state {S0, ...S5} using a 128bit value.
Inputs:

msg: the block to be absorbed.
Modifies:
Steps:
The Absorb Function
The Absorb function absorbs a 128bit input block ai into the state {S0, ...S5}.
Inputs:
Steps:
The Enc Function
The Enc function encrypts a 128bit input block xi using the state {S0, ...S5}.
Inputs:
Outputs:

ci: the encrypted input block.
Steps:
The Dec Function
The Dec function decrypts a 128bit input block ci using the state {S0, ...S5}.
Inputs:

ci: the encrypted input block.
Outputs:
Steps:
The DecPartial Function
The DecPartial function decrypts the last ciphertext bits cn using the state {S0, ...S5} when they do not fill an entire block.
Inputs:
Outputs:

xn: the decryption of cn.
Steps:
The Finalize Function
The Finalize function computes a 128 or 256bit tag that authenticates the message and associated data.
Inputs:

ad_len_bits: the length of the associated data in bits.

msg_len_bits: the length of the message in bits.
Outputs:

tag: the authentication tag.
Steps:
Encoding (ct, tag) Tuples
Applications MAY keep the ciphertext and the authentication tag in distinct structures or encode both as a single string.
In the latter case, the tag MUST immediately follow the ciphertext:
Security Considerations
AEGIS256 offers 256bit message security against plaintext and state recovery, whereas AEGIS128L offers 128bit security.
An authentication tag may verify under multiple keys, nonces, or associated data. Assuming AEGIS is fully committing, finding different inputs producing the same tag is expected to require ~2^{64} attempts with a 128bit authentication tag and ~2^{128} attempts with a 256bit tag.
Under the assumption that the secret key is unknown to the attacker and a 128bit tag is used, both AEGIS128L and AEGIS256 target 128bit security against forgery attacks. With a 256bit tag, AEGIS256 targets 256bit security against forgery attacks, whereas AEGIS128L continues to target 128bit security.
Both algorithms MUST be used in a noncerespecting setting: for a given key, a nonce MUST only be used once. Failure to do so would immediately reveal the bitwise difference between two messages.
If tag verification fails, the decrypted message and wrong message authentication tag MUST NOT be given as output. As shown in the analysis of the (robustness of CAESAR candidates beyond their guarantees), even a partial leak of the plaintext without verification would facilitate chosen ciphertext attacks.
Every key MUST be randomly chosen from a uniform distribution.
The nonce MAY be public or predictable. It can be a counter, the output of a permutation, or a generator with a long period.
With AEGIS128L, random nonces can safely encrypt up to 2^{48} messages using the same key with negligible (~ 2^{33}, to align with NIST guidelines) collision probability.
With AEGIS256, random nonces can be used with no practical limits.
The security of AEGIS against timing and physical attacks is limited by the implementation of the underlying AESRound() function. Failure to implement AESRound() in a fashion safe against timing and physical attacks, such as differential power analysis, timing analysis or fault injection attacks, may lead to leakage of secret key material or state information. The exact mitigations required for timing and physical attacks also depend on the threat model in question.
Security analyses of AEGIS can be found in Chapter 4 of , in , in , in , in , and in .
IANA Considerations
IANA has assigned the following identifiers in the AEAD Algorithms Registry:
AEGIS entries in the AEAD Algorithms Registry
Algorithm Name 
ID 
AEAD_AEGIS128L 
32 
AEAD_AEGIS256 
33 
IANA has also assigned the following TLS cipher suites in the TLS Cipher Suite Registry:
AEGIS entries in the TLS Cipher Suite Registry
Cipher Suite Name 
Value 
TLS_AEGIS_256_SHA384 
{0x13,0x06} 
TLS_AEGIS_128L_SHA256 
{0x13,0x07} 
IANA is requested to update the references of these entries to refer to the final version of this document.
QUIC and DTLS 1.3 Header Protection
DTLS 1.3 Record Number Encryption
In DTLS 1.3, record sequence numbers are encrypted as specified in [RFC9147].
For AEGIS128L and AEGIS256, the mask is generated using the AEGIS Encrypt function with:
 a 128bit tag length

sn_key, as defined in Section 4.2.3 of [RFC9147]

ciphertext[0..16]: the first 16 bytes of the DTLS ciphertext

nonce_len: the AEGIS nonce length
The mask is computed as follows:
QUIC Header Protection
In QUIC, parts of the QUIC packet headers are encrypted as specified in [RFC9001].
For AEGIS128L and AEGIS256, the mask is generated using the AEGIS Encrypt function with:
 a 128bit tag length

hp_key, as defined in Section 5.4 of [RFC9001]

sample: the 16 bytes QUIC ciphertext sample

nonce_len: the AEGIS nonce length
The mask is computed as follows:
References
Normative References
Advanced encryption standard (AES)
National Institute of Standards and Technology
US
Gaithersburg
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
An Interface and Algorithms for Authenticated Encryption
This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an applicationindependent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDSTRACK]
Informative References
AEGIS: A fast encryption algorithm (v1.1)
Nanyang Technological University
KU Leuven
GuessandDetermine Attacks on AEGIS
State Key Laboratory of Cryptology, Beijing
State Key Laboratory of Information Security, Institute of Information Engineering, Chinese Academy of Sciences; School of Cyber Security, University of Chinese Academy of Sciences
State Key Laboratory of Cryptology, Beijing
The Computer Journal
Weak Keys in Reduced AEGIS and Tiaoxin
East China Normal University; University of Hyogo
University of Hyogo; National Institute of Information and Communications Technology; PRESTO, Japan Science and Technology Agency
University of Applied Sciences and Arts Northwestern Switzerland
University of Hyogo
IACR Transactions on Symmetric Cryptology, 2021(2), pp. 104–139
Partitioning Oracle Attacks
Cornell Tech
Cornell Tech
Cornell Tech
30th USENIX Security Symposium (USENIX Security 21), pp. 195–212
Analyzing the Linear Keystream Biases in AEGIS
Graz University of Technology
Graz University of Technology
Graz University of Technology
IACR Transactions on Symmetric Cryptology, 2019(4), pp. 348–368
Can Caesar Beat Galois? Robustness of CAESAR Candidates against Nonce Reusing and High Data Complexity Attacks
École Polytechnique Fédérale de Lausanne EPFL
École Polytechnique Fédérale de Lausanne EPFL
Applied Cryptography and Network Security. ACNS 2018. Lecture Notes in Computer Science, vol 10892, pp. 476–494
Linear Biases in AEGIS Keystream
Agence nationale de la sécurité des systèmes d'information ANSSI
Selected Areas in Cryptography. SAC 2014. Lecture Notes in Computer Science, vol 8781, pp. 290–305
MILPbased security evaluation for AEGIS/Tiaoxin346/Rocca
University of Hyogo
University of Hyogo
University of Hyogo
University of Hyogo; National Institute of Information and Communications Technology
IET Information Security, 2023, pp. 110
Test Vectors
AEGIS128L Test Vectors
Test Vector 6
This test MUST return a “verification failed” error.
Test Vector 7
This test MUST return a “verification failed” error.
Test Vector 8
This test MUST return a “verification failed” error.
Test Vector 9
This test MUST return a “verification failed” error.
AEGIS256 Test Vectors
Test Vector 6
This test MUST return a “verification failed” error.
Test Vector 7
This test MUST return a “verification failed” error.
Test Vector 8
This test MUST return a “verification failed” error.
Test Vector 9
This test MUST return a “verification failed” error.
Acknowledgments
The AEGIS authenticated encryption algorithm was invented by Hongjun Wu and Bart Preneel.
The round function leverages the AES permutation invented by Joan Daemen and Vincent Rijmen. They also authored the Pelican MAC that partly motivated the design of the AEGIS MAC.
We would like to thank Eric Lagergren and Daniel Bleichenbacher for catching a broken test vector and Daniel Bleichenbacher for many helpful suggestions.
We would also like to thank John Preuß Mattsson for his review of the draft, and for suggesting how AEGIS should be used in the context of DTLS and QUIC.