Decoding the Specification and Structure of RFC 10032: The AEGIS Authenticated Encryption Algorithms

ネットワーク・RFCカテゴリを表すパンダのイラスト Networking / RFC

This article is a technical explanation and implementation example generated using AI. Although the code and procedures presented are based on primary sources, they have not been verified on actual hardware by the author. Behavior may vary depending on the environment and version. Based on the official specifications, this article systematically and practically organizes the components and processing mechanisms of the AEGIS family of high-speed authenticated encryption with associated data (AEAD) algorithms defined in RFC 10032. We will examine in detail the characteristics of each variant, such as AEGIS-128L and AEGIS-256, the method for updating internal states, and the message encryption and decryption processes.


1. Overview and Positioning of the AEGIS Family

AEGIS is a family of AEAD algorithms selected for high-performance applications during the CAESAR competition. As an output of the Crypto Forum Research Group (CFRG), it is compiled as Informational in RFC 10032.

Compared to existing constructs such as AES-GCM, it delivers superior performance on CPUs equipped with AES instructions and also operates rapidly in software implementations that do not use AES instructions. Furthermore, AEGIS-256 and AEGIS-256X allow random nonces to be selected securely without practical limitations.

The primary sources define the following main variants:

  • AEGIS-128L: Features a 128-bit key, 128-bit nonce, 1024-bit state (eight 128-bit blocks), a 128- or 256-bit authentication tag, and processes 256-bit input blocks.

  • AEGIS-256: Features a 256-bit key, 256-bit nonce, 768-bit state (six 128-bit blocks), a 128- or 256-bit authentication tag, and processes 128-bit input blocks.

  • AEGIS-128X: A mode based on AEGIS-128L, specialized for CPUs with large vector registers and vector AES instructions.

  • AEGIS-256X: A mode based on AEGIS-256, specialized for CPUs with large vector registers and vector AES instructions.

All variants feature an inverse-free structure, constructed by combining AES encryption round functions (AESRound).


2. Primitives and Common Definitions

RFC 10032 defines several basic operators and functions to describe the algorithm specifications.

  • {}: Empty bit array

  • |x|: Bit length of $x$

  • a ^ b: Bitwise exclusive OR (XOR)

  • a & b: Bitwise AND

  • a || b: Concatenation

  • LE64(x): Little-endian encoding of an unsigned 64-bit integer $x$

  • Zeros(n): An $n$-bit array of all zeros

  • ZeroPad(x, n): A function that appends zero padding such that the length becomes a multiple of $n$ bits

  • AESRound(in, rk): SubBytes、ShiftRows、MixColumns、AddRoundKey, combining a single AES round function

Additionally, as constant blocks, C0 and C1 comprising 16-byte hexadecimal values are defined.


3. Structure and Internal Functions of AEGIS-128L

AEGIS-128L maintains a 1024-bit state, consisting of eight 128-bit blocks ${S_0, \dots, S_7}$. Here, the roles of the main internal functions are organized.

flowchart TD
    Init["Init(key, nonce)"] --> Absorb["Absorb(ai) <br/> 関連データの吸収"]
    Absorb --> EncDec["Enc(xi) / Dec(ci) <br/> ブロックの暗号化・復号"]
    EncDec --> Finalize["Finalize(ad_len, msg_len) <br/> 認証タグ生成"]

Initialization Function (Init)

Init(key, nonce) constructs the initial state ${S_0, \dots, S_7}$ using the given key and nonce. After placing the key and nonce XORs and the constant block C0、C1 into the initial state, it performs mixing by repeating the Update function 10 times.

State Update Function (Update)

Update(M0, M1) is the core state update function of AEGIS-128L. It takes two 128-bit values (or blocks) and sequentially updates the eight state blocks ${S_0, \dots, S_7}$ while applying the AES round function.

Encryption and Decryption (Enc / Dec)

Encrypt and Decrypt processes sequentially absorb the padded associated data using the Absorb function, and then perform encryption (Enc) or decryption (Dec) in message block units. For the trailing incomplete block, DecPartial is applied.

The tag generation function (Finalize)

Finalize(ad_len_bits, msg_len_bits) calculates the tag by incorporating the associated data and message lengths. The output format differs depending on whether the tag length is 128 bits or 256 bits, and it is used for data tampering detection.


4. Security Characteristics and Design Considerations

RFC 10032 describes resistance to issues pointed out in conventional AEAD schemes (such as AES-GCM) and the security advantages specific to AEGIS.

  1. Resistance to Partition Oracle Attacks: In some modes such as AES-GCM, an attacker can sometimes generate ciphertexts that can be successfully decrypted with multiple different keys, which may be exploited to streamline password searches. On the other hand, in AEGIS, the difficulty of finding pairs of different keys and nonces depends on the tag size, and sufficient security is ensured by the 128-bit or 256-bit tags.

  2. Mitigation of State Leakage Impact: Unlike many AES-based constructions, even if a portion of the internal state leaks, the structure prevents the key or past states from leaking directly.

  3. Protection of Ephemeral Keys: AEGIS keys do not need to be retained after the execution of the initialization function, and there is no key schedule. This allows ephemeral keys to be purged from memory prior to data encryption and decryption, mitigating the risk of cold-boot attacks.

  4. Prohibition of Nonce Reuse: As a security requirement, nonces must not be reused for the same key. Strict management is required because nonce reuse allows recovery of the internal state.


5. AEGIS-256 Specification Differences

AEGIS-256 is a variant designed for applications requiring a larger security margin. The main differences from AEGIS-128L are as follows.

  • State size: 768 bits (six 128-bit blocks ${S_0, \dots, S_5}$)

  • Key length and nonce length: 32 bytes (256 bits)

  • Input block size: 128 bits

While the framework for parameters and operational constraints (such as P_MAX and A_MAX compliant with RFC 5116) remains the same, the internal block length and state array sizes differ. Therefore, implementations must strictly follow the specifications of the target algorithm.


6. Conclusion

This article outlines the specifications and structures of the AEGIS authenticated encryption algorithms defined in RFC 10032, based on primary sources.

  • Key points:

    • The AEGIS family is a set of inverse-free, AES-based AEAD algorithms designed for high-performance applications.

    • Multiple variants exist, including AEGIS-128L (1024-bit state) and AEGIS-256 (768-bit state).

    • There is no key schedule, and keys can be immediately erased after initialization, which helps mitigate cold-boot attacks.

    • Reusing a nonce with the same key is strictly prohibited, and secure random number generation or management is essential.

    • The contents of this article are based on research and explanations from official standard documents, and no operational verification has been performed on physical hardware.


References

Document information

Article title
Decoding the Specification and Structure of RFC 10032: The AEGIS Authenticated Encryption Algorithms
Published
Updated
Source
https://papanda925.com/?p=17669&lang=en

License: Text and original figures for which this site holds the relevant rights are available under CC BY 4.0 , unless otherwise noted. This article may include content created or edited with generative AI. If code has a separate license notice or a linked GitHub repository license, that license takes precedence for the code. Quotations, third-party materials, images, and trademarks are excluded from this license. Usage policy

Copied title and URL