]>
The AEGIS Family of Authenticated Encryption Algorithms
Fastly Inc.
fde@00f.net
Individual Contributor
samuellucas6@pm.me
Crypto Forum
InternetDraft
This document describes the AEGIS128L, AEGIS256, AEGIS128X, and AEGIS256X AESbased authenticated encryption algorithms designed for highperformance applications.
The 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 AEGIS family of authenticated encryption with associated data (AEAD) algorithms , which were chosen for highperformance applications in the CAESAR (Competition for Authenticated Encryption: Security, Applicability, and Robustness) competition.
Among the finalists, AEGIS128 was chosen as the winner for this category. However, AEGIS128L, another finalist, offers enhanced performance and a stronger security margin .
Additionally, AEGIS256, which also reached the final round, provides 256bit security and supports higher usage limits.
Therefore, this document specifies the following variants:

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.

AEGIS128X, which is a mode based on AEGIS128L, specialized for CPUs with large vector registers and vector AES instructions.

AEGIS256X, which is a mode based on AEGIS256, specialized for CPUs with large vector registers and vector AES instructions.
All variants are inversefree and constructed from the AES encryption round function .
The AEGIS cipher family offers performance that significantly exceeds that of AESGCM on CPUs with AES instructions. Similarly, software implementations not using AES instructions 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 and AEGIS256X. AEGIS128L and AEGIS128X also allow 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 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 AEGIS, finding distinct (key, nonce) pairs that successfully decrypt a given (associated data, ciphertext, authentication tag) tuple is believed to have 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.
Unlike most other AESbased AEAD constructions, leaking a state does not leak the key or previous states.
Finally, an AEGIS key is not required after the initialization function, and there is no key schedule. Thus, ephemeral keys can be erased from memory before any data has been encrypted or decrypted, mitigating cold boot attacks.
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 state updates in the Finalize() function. We follow the specification of , 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.
Throughout this document, “byte” is used interchangeably with “octet” and refers to an 8bit sequence.
Primitives:

{}: an empty bit array.

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) or Update(M): 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 bytes (128 bits).

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

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

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

C_MAX (maximum ciphertext length) = P_MAX + tag length = (2^{61}  1) + 16 or 32 bytes (in bits: (2^{64}  8) + 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 or equal to P_MAX).

ad: the associated data to authenticate (length MUST be less than or equal to 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 or equal to C_MAX).

tag: the authentication tag.

ad: the associated data to authenticate (length MUST be less than or equal to 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 bytes (256 bits).

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

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

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

C_MAX (maximum ciphertext length) = P_MAX + tag length = (2^{61}  1) + 16 or 32 bytes (in bits: (2^{64}  8) + 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 or equal to P_MAX).

ad: the associated data to authenticate (length MUST be less than or equal to 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 or equal to C_MAX).

tag: the authentication tag.

ad: the associated data to authenticate (length MUST be less than or equal to 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:
Parallel Modes
Some CPUs, such as Intel and Intelcompatible CPUs with the VAES extensions, include instructions to efficiently apply the AES round function to a vector of AES blocks.
AEGIS128X and AEGIS256X are optional, specialized modes designed to take advantage of these instructions. They share the same properties as the ciphers they are based on but can be significantly faster on these platforms, even for short messages.
AEGIS128X and AEGIS256X are parallel evaluations of multiple AEGIS128L and AEGIS256 instances respectively, with distinct initial states. On CPUs with wide vector registers, different states can be stored in different 128bit lanes of the same vector register, allowing parallel updates using vector instructions.
The modes are parameterized by the parallelism degree. With 256bit registers, 2 parallel operations can be applied to 128bit AES blocks. With 512bit registers, the number of instances can be raised to 4.
The state of a parallel mode is represented as a vector of AEGIS128L or AEGIS256 states.
Additional Conventions and Definitions

D: the degree of parallelism.

R: the absorption and output rate of the mode. With AEGIS128X, the rate is 2 * 128 * D bits. With AEGIS256X, the rate is 128 * D bits.

V[j,i]: the jth AES block of the ith state. i is in the [0..D) range. For AEGIS128X, j is in the [0..8) range, while for AEGIS256, j is in the [0..6) range.

V'[j,i]: the jth AES block of the next ith state.

ctx[i]: the ith context separator. This is a 128bit mask, made of a byte representing the state index, followed by a byte representing the highest index and 112 allzero bits.

Byte(x): the value x encoded as 8 bits.
Authenticated Encryption
The Encrypt function of AEGIS128X resembles that of AEGIS128L, and similarly, the Encrypt function of AEGIS256X mirrors that of AEGIS256, but processes Rbit input blocks per update.
Steps:
Authenticated Decryption
The Decrypt function of AEGIS128X resembles that of AEGIS128L, and similarly, the Decrypt function of AEGIS256X mirrors that of AEGIS256, but processes Rbit input blocks per update.
Steps:
AEGIS128X
The Init Function
The Init function initializes a vector of D AEGIS128L states with the same key and nonce but a different context ctx[i]. The context is added to the state before every update.
Steps:
The Update Function
The AEGIS128X Update function is similar to the AEGIS128L Update function, but absorbs R (2 * 128 * D) bits at once. M0 and M1 are 128 * D bits instead of 128 bits but are split into 128bit blocks, each of them updating a different AEGIS128L state.
Steps:
The Absorb Function
The Absorb function is similar to the AEGIS128L Absorb function, but absorbs R bits instead of 256 bits.
Steps:
The Enc Function
The Enc function is similar to the AEGIS128L Enc function, but encrypts R bits instead of 256 bits.
Steps:
The Dec Function
The Dec function is similar to the AEGIS128L Dec function, but decrypts R bits instead of 256 bits.
Steps:
The DecPartial Function
The DecPartial function is similar to the AEGIS128L DecPartial function, but decrypts up to R bits instead of 256 bits.
Steps:
The Finalize Function
The Finalize function finalizes every AEGIS128L instance and combines the resulting authentication tags using the bitwise exclusive OR operation.
Steps:
AEGIS256X
The Init Function
The Init function initializes a vector of D AEGIS256 states with the same key and nonce but a different context ctx[i]. The context is added to the state before every update.
Steps:
The Update Function
The AEGIS256X Update function is similar to the AEGIS256 Update function, but absorbs R (128 * D) bits at once. M is 128 * D bits instead of 128 bits and is split into 128bit blocks, each of them updating a different AEGIS256 state.
Steps:
The Absorb Function
The Absorb function is similar to the AEGIS256 Absorb function, but absorbs R bits instead of 128 bits.
Steps:
The Enc Function
The Enc function is similar to the AEGIS256 Enc function, but encrypts R bits instead of 128 bits.
Steps:
The Dec Function
The Dec function is similar to the AEGIS256 Dec function, but decrypts R bits instead of 128 bits.
Steps:
The DecPartial Function
The DecPartial function is similar to the AEGIS256 DecPartial function, but decrypts up to R bits instead of 128 bits.
Steps:
The Finalize Function
The Finalize function finalizes every AEGIS256 instance and combines the resulting authentication tags using the bitwise exclusive OR operation.
Steps:
Implementation Considerations
AEGIS128X and AEGIS256X with a degree of 1 are identical to AEGIS128L and AEGIS256. This property can be used to reduce the code size of a generic implementation.
In AEGIS128X, V can be represented as eight 256bit registers (when D = 2) or eight 512bit registers (when D = 4). In AEGIS256X, V can be represented as six 256bit registers (when D = 2) or six 512bit registers (when D = 4). With this representation, loops over 0..D in the above pseudocode can be replaced by vector instructions.
Operational Considerations
The AEGIS parallel modes are specialized and can only improve performance on specific CPUs.
The degrees of parallelism implementations are encouraged to support are 2 (for CPUs with 256bit registers) and 4 (for CPUs with 512bit registers). The resulting algorithms are called AEGIS128X2, AEGIS128X4, AEGIS256X2, and AEGIS256X4.
The following table summarizes how many bits are processed in parallel (rate), the memory requirements (state size), and the minimum vector register sizes a CPU should support for optimal performance.
Algorithm 
Rate (bits) 
Optimal Register Size 
State Size (bits) 
AEGIS128L 
256 
128 bits 
1024 
AEGIS128X2 
512 
256 bits 
2048 
AEGIS128X4 
1024 
512 bits 
4096 
AEGIS256 
128 
128 bits 
768 
AEGIS256X2 
256 
256 bits 
1536 
AEGIS256X4 
512 
512 bits 
3072 
Note that architectures with smaller vector registers but with many registers and large pipelines may still benefit from the parallel modes.
Protocols SHOULD opt for a parallel mode only when all the involved parties agree on a specific variant. AEGIS128L and AEGIS256 SHOULD remain the default choices.
Implementations MAY choose not to include the parallel AEGIS modes.
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:
AEGIS as a Stream Cipher
All AEGIS variants can also be used as stream ciphers.
The Stream function expands a key and an optional nonce into a variablelength, secure keystream.
Inputs:

len: the length of the keystream to generate in bits.

key: the AEGIS key.

nonce: the nonce. If unspecified, it is set to N_MAX zero bytes.
Outputs:
Steps:
This is equivalent to encrypting a len allzero bits message without associated data, and discarding the authentication tag.
Instead of relying on the generic Encrypt function, implementations can skip the finalization step.
After initialization, the Update function is called with constant parameters, allowing further optimizations.
Implementation Status
This note is to be removed before publishing as an RFC.
Multiple implementations of the schemes described in this document have been developed and verified for interoperability.
A comprehensive list of known implementations and integrations can be found at , which includes reference implementations closely aligned with the pseudocode provided in this document.
Security Considerations
Usage Guidelines
Key and Nonce Selection
All AEGIS variants MUST be used in a noncerespecting setting: for a given key, a nonce MUST only be used once, even with different tag lengths. Failure to do so would immediately reveal the bitwise difference between two messages.
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 and AEGIS128X, 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 and AEGIS256X, random nonces can be used with no practical limits.
Key Commitment
An authentication tag may verify under multiple keys, nonces, or associated data, but AEGIS is assumed to be key committing in the receiverbinding game, preventing common attacks when used with lowentropy keys such as passwords. Finding distinct keys and/or nonces that successfully verify the same (ad, ct, tag) tuple is expected to require ~2^{64} attempts with a 128bit authentication tag and ~2^{128} attempts with a 256bit tag.
AEGIS is fully committing in the restricted setting where an adversary cannot control the associated data. As shown in , with the ability to alter the associated data, it is possible to efficiently find multiple keys that will verify the same authenticated ciphertext.
Protocols mandating a fully committing scheme without that restriction can provide the associated data as input to a cryptographic hash function and use the output as the ad parameter of the Encrypt and Decrypt functions. The selected hash function must ensure a minimum of 128bit preimage resistance. An instance of such a function is SHA256 .
Alternatively, the associated data can be fed into a collisionresistant KDF, such as HKDF , via the info input to derive the key parameter. The ad parameter can then be left empty. Note that the salt input MUST NOT be used since large salts get hashed, which affects commitment. Furthermore, this requires values concatenated to form the info input to be unambiguously encoded, like by appending their lengths.
MultiUser Security
AEGIS nonces match the size of the key. AEGIS128L and AEGIS128X feature 128bit nonces, offering an extra 32 bits compared to the commonly used AEADs in IETF protocols. The AEGIS256 and AEGIS256X variants provide even larger nonces. With 192 random bits, 64 bits remain available to optionally encode additional information.
In all these variants, unused nonce bits can encode a key identifier, enhancing multiuser security. If every key has a unique identifier, multitarget attacks don’t provide any advantage over singletarget attacks.
Other Uses of AEGIS
All variants can be used as a MAC by calling the Encrypt() function with the message as the ad and leaving msg empty, resulting in just a tag. However, they MUST NOT be used as a hash function; if the key is known, inputs generating state collisions can easily be crafted. Similarly, as opposed to hashbased MACs, tags MUST NOT be used for key derivation as there is no proof they are uniformly random.
Implementation Security
If tag verification fails, the unverified plaintext and the computed message authentication tag MUST NOT be released. As shown in , even a partial leak of the plaintext without verification would facilitate chosen ciphertext attacks.
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.
Regardless of the variant, the key and nonce are only required by the Init function; other functions only depend on the resulting state. Therefore, implementations can overwrite ephemeral keys with zeros right after the last Update call of the initialization function.
Security Guarantees
AEGIS256 offers 256bit message security against plaintext and state recovery, whereas AEGIS128L offers 128bit security.
Under the assumption that the secret key is unknown to the attacker, all AEGIS variants offer at least 128bit security against forgery attacks.
Encrypting the same message with the same key and nonce but different associated data generates distinct ciphertexts that do not reveal any additional information about the message.
AEGIS has been shown to have reforgeability resilience in . Without the ability to set the associated data, a successful forgery does not increase the probability of subsequent forgeries.
AEGIS128X and AEGIS256X share the same security properties and requirements as AEGIS128L and AEGIS256 respectively. In particular, the security level and usage limits remain the same .
AEGIS is considered secure against guessanddetermine attacks aimed at recovering the state from observed ciphertexts.
This resilience extends to quantum adversaries operating within the Q1 model, where the attacker has access to a quantum computer but is restricted to classical (nonquantum) communications with the systems under attack. In this model, quantum attacks offer no practical advantage in decrypting previously recorded ciphertexts or in recovering the encryption key.
This document extends the original specification by introducing optional support for 256bit authentication tags, which are constructed similarly to the 128bit tags.
As shown in , with 256bit tags, all AEGIS variants achieve more than 128bit security against forgery by differential attacks.
Security analyses of AEGIS can be found in , , , , , , , , , , and .
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 is requested to update the references of these entries to refer to the final version of this document.
IANA is also requested to register the following identifiers in the AEAD Algorithms Registry:

AEAD_AEGIS128X2

AEAD_AEGIS128X4

AEAD_AEGIS256X2

AEAD_AEGIS256X4
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]
US Secure Hash Algorithms (SHA and SHAbased HMAC and HKDF)
Federal Information Processing Standard, FIPS
HMACbased ExtractandExpand Key Derivation Function (HKDF)
This document specifies a simple Hashed Message Authentication Code (HMAC)based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
Informative References
AEGIS: A Fast Authenticated Encryption Algorithm (v1.1)
Nanyang Technological University
KU Leuven
Differential fault attack on AESbased encryption schemes: application to B5G/6G ciphers—Rocca, RoccaS and AEGIS
Indraprastha Institute of Information Technology Delhi; University of Hyogo
University of Hyogo
Indian Statistical Institute Kolkata
University of Hyogo
University of Hyogo; Indian Institute of Technology Bhilai
Journal of Cryptographic Engineering, 2024
Singlequery Quantum Hidden Shift Attacks
Université de Lorraine, CNRS, Inria, LORIA
Université de Rennes, CNRS, Inria, IRISA
Cryptology ePrint Archive, Paper 2023/1306
Adding more parallelism to the AEGIS authenticated encryption algorithms
Fastly Inc.
Cryptology ePrint Archive, Paper 2023/523
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
Reforgeability of Authenticated Encryption Schemes
Beuth Hochschule für Technik Berlin
BauhausUniversität Weimar
BauhausUniversität Weimar
BauhausUniversität Weimar
Cryptology ePrint Archive, Paper 2017/332
Key Committing Security Analysis of AEGIS
University of Hyogo
University of Hyogo
Cryptology ePrint Archive, Paper 2023/1495
GuessandDetermine Attacks on AEGIS
State Key Laboratory of Cryptology
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
The Computer Journal, vol 65, 2022(8), pp. 2221–2230
Partitioning Oracle Attacks
Cornell Tech
Cornell Tech
Cornell Tech
30th USENIX Security Symposium (USENIX Security 21), pp. 195–212
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
Linear Biases in AEGIS Keystream
ANSSI
Selected Areas in Cryptography. SAC 2014. Lecture Notes in Computer Science, vol 8781, pp. 290–305
BitWise Analysis for Forgery Attacks on AESBased AEAD Schemes
University of Hyogo
Mitsubishi Electric Corporation
University of Hyogo
Advances in Information and Computer Security. IWSEC 2024. Lecture Notes in Computer Science, vol 14977
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, vol 17, 2023(3), pp. 458467
AEGIS Test Vectors
commit 7e4a38d1
Can Caesar Beat Galois?
EPFL
EPFL
Applied Cryptography and Network Security. ACNS 2018. Lecture Notes in Computer Science, vol 10892, pp. 476–494
Test Vectors
The following test vectors are also available in JSON format at . In this format, byte strings are represented as JSON strings containing their hexadecimal encoding.
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.
AEGIS128X2 Test Vectors
Initial State
After initialization:
AEGIS128X4 Test Vectors
Initial State
After initialization:
AEGIS256X2 Test Vectors
Initial State
After initialization:
AEGIS256X4 Test Vectors
Initial State
After initialization:
Acknowledgments
The AEGIS authenticated encryption algorithm was invented by Hongjun Wu and Bart Preneel.
The state update function leverages the AES permutation invented by Joan Daemen and Vincent Rijmen. They also authored the Pelican MAC, which partly motivated the design of the AEGIS MAC.
We would like to thank the following individuals for their contributions:

Eric Lagergren and Daniel Bleichenbacher for catching a broken test vector and Daniel Bleichenbacher for many helpful suggestions.

John Preuß Mattsson for his review of the draft, and for suggesting how AEGIS should be used in the context of DTLS and QUIC.

Bart Mennink and Charlotte Lefevre as well as Takanori Isobe and Mostafizar Rahman for investigating the commitment security of the schemes specified in this document.

Scott Fluhrer for his review of the draft as a member of the CFRG Crypto Panel.