]> Fastly Inc.

fd@00f.net

Huawei

pham.phuong@huawei.com

Huawei

lucas.prabel@huawei.com

Huawei

sunshuzhou@huawei.com

Internet-Draft This document describes HiAE, a high-throughput authenticated encryption algorithm designed for next-generation wireless systems (6G) and high-speed data transmission applications. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction The evolution of wireless networks toward 6G, alongside the growing demands of cloud service providers and CDN operators, requires cryptographic algorithms capable of delivering unprecedented throughput while maintaining strong security guarantees. Current high-performance authenticated encryption schemes achieve impressive speeds by leveraging platform-specific SIMD instructions, particularly AES-NI on x86 architectures . Notable examples include AEGIS , SNOW-V , and Rocca-S . While these platform-specific optimizations deliver high performance on their target architectures, they create a significant performance disparity across different hardware platforms. These algorithms excel on x86 processors equipped with AES-NI but exhibit substantially degraded performance on ARM architectures that implement SIMD functionality through NEON instructions. This inconsistency poses a critical challenge for modern network deployments where ARM processors dominate mobile devices, edge computing nodes, and increasingly, data center environments. The architectural differences between x86 and ARM extend beyond instruction set variations. They encompass fundamental distinctions in how AES round functions are implemented in hardware, pipeline structures, and memory subsystems. These differences mean that algorithms optimized for one architecture may inadvertently create bottlenecks on another, resulting in unpredictable performance characteristics across heterogeneous deployments. The transition to 6G networks amplifies these challenges. Next-generation wireless systems will rely heavily on software-defined networking (SDN) and cloud radio access networks (Cloud RAN), requiring cryptographic algorithms that perform consistently across diverse hardware platforms. The stringent latency requirements and massive data rates anticipated for 6G, potentially exceeding 1 Tbps, demand encryption schemes that can leverage the full capabilities of both x86 and ARM architectures without compromise. This document presents HiAE (High-throughput Authenticated Encryption), an authenticated encryption algorithm explicitly designed to address these cross-platform performance challenges. Through careful algorithmic design, HiAE delivers high performance on both x86 and ARM architectures by efficiently utilizing the capabilities of each platform without being overly dependent on architecture-specific features.

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 8-bit sequence. Basic operations:

• {}: an empty bit array.
• { 0 }: a single zero byte (8 zero bits).
• |x|: the length of x in bits.
• a ^ b: the bitwise exclusive OR 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.

Data manipulation:

• LE64(x): returns the little-endian encoding of unsigned 64-bit integer x.
• ZeroPad(x, n): returns x after appending zeros until its length is a multiple of n bits. No padding is added if the length of x is already a multiple of n, including when x is empty.
• Truncate(x, n): returns the first n bits of x.
• Tail(x, n): returns the last n bits of x.
• Split(x, n): returns x split into n-bit blocks, ignoring partial blocks.

Cryptographic operations:

• AESL(x): A single AES round function without key addition. Given a 128-bit AES state x, this function applies the following AES transformations in sequence:
  1. SubBytes: Apply the AES S-box to each byte
  2. ShiftRows: Cyclically shift the rows of the state
  3. MixColumns: Mix the columns of the state
  Formally: AESL(x) = MixColumns(ShiftRows(SubBytes(x))) These transformations are as specified in Section 5 of . This is NOT the full AES encryption algorithm. It is a single round without the AddRoundKey operation (equivalent to using a zero round key). A test vector for this function is provided in the Test Vectors section. While Intel AES-NI and ARM NEON provide instructions with similar parameters and descriptions (such as _mm_aesenc_si128 on Intel and vaesmcq_u8(vaeseq_u8(...)) on ARM), these instructions are not functionally equivalent. The architectural differences in how AES round functions are implemented require platform-specific optimization strategies, as detailed in the Implementation Considerations section.

Control flow and comparison:

• Repeat(n, F): n sequential evaluations of F.
• CtEq(a, b): compares a and b in constant-time, returning True for an exact match and False otherwise.

AES blocks:

• Si: the i-th AES block of the current state.
• S'i: the i-th AES block of the next state.
• {Si, ...Sj}: the vector of the i-th AES block of the current state to the j-th block of the current state.
• C0: an AES block built from the following bytes in hexadecimal format: { 0x32, 0x43, 0xf6, 0xa8, 0x88, 0x5a, 0x30, 0x8d, 0x31, 0x31, 0x98, 0xa2, 0xe0, 0x37, 0x07, 0x34 }.
• C1: an AES block built from the following bytes in hexadecimal format: { 0x4a, 0x40, 0x93, 0x82, 0x22, 0x99, 0xf3, 0x1d, 0x00, 0x82, 0xef, 0xa9, 0x8e, 0xc4, 0xe6, 0xc8 }.
• ZERO: an AES block of all zeros (128 zero bits).

The constants C0 and C1 are domain separation constants derived from the fractional parts of π and e, respectively. Input and output values:

• key: the encryption key (256 bits).
• nonce: the public nonce (128 bits).
• ad: the associated data.
• msg: the plaintext.
• ct: the ciphertext.
• tag: the authentication tag (128 bits).

The HiAE Algorithm This section provides the complete specification of HiAE. The algorithm operates on a 2048-bit internal state organized as sixteen 128-bit blocks, combining AES round functions with an efficient update mechanism to achieve both high security and cross-platform performance.

Algorithm Parameters HiAE maintains a 2048-bit state organized as sixteen 128-bit blocks denoted {S0, S1, S2, ..., S15}. Each block Si represents a 128-bit AES state that can be processed independently by AES round functions. This large state size provides security margins while enabling efficient parallel processing on modern architectures. 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⁶¹ - 1 bytes (2⁶⁴ - 8 bits).
• A_MAX (maximum length of the associated data) is 2⁶¹ - 1 bytes (2⁶⁴ - 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⁶¹ - 1) + 16 bytes ((2⁶⁴ - 8) + 128 bits).

Distinct associated data inputs, as described in , MUST 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 fails. Security:

• If tag verification fails, the decrypted message and incorrect authentication tag MUST NOT be given as output. The decrypted message MUST be overwritten with zeros before the function returns.
• The comparison of the input tag with the expected_tag MUST be done in constant time.

Inputs:

• ct: the ciphertext to decrypt (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:

Core Functions The following sections describe the fundamental operations that form the building blocks of HiAE. These functions manipulate the 2048-bit state to provide confusion, diffusion, and the absorption of input data.

The State Rotation Function The Rol function provides diffusion by rotating the sixteen 128-bit blocks of the state one position to the left. This ensures that local changes propagate throughout the entire state over multiple rounds. Modifies:

• {S0, ...S15}: the state.

Steps:

The State Update Functions The state update functions form the cryptographic core of HiAE. They combine the AESL transformation with XOR operations and state rotation to achieve both security and efficiency.

The Update Function The Update function is the core of the HiAE algorithm. It updates the state {S0, ...S15} using a 128-bit value. Inputs:

• xi: the 128-bit block to be absorbed.

Modifies:

• {S0, ...S15}: the state.

Steps:

The UpdateEnc Function The UpdateEnc function extends the basic Update function to provide encryption. It absorbs a plaintext block while simultaneously generating the corresponding ciphertext block through an additional XOR with state block S9. Inputs:

• mi: a 128-bit block to be encrypted.

Outputs:

• ci: the encrypted 128-bit block.

Modifies:

• {S0, ...S15}: the state.

Steps:

The UpdateDec Function The UpdateDec function provides the inverse operation of UpdateEnc. It processes a ciphertext block to recover the plaintext while maintaining the same state update pattern, ensuring that encryption and decryption produce identical internal states. Inputs:

• ci: a 128-bit block to be decrypted.

Outputs:

• mi: the decrypted 128-bit block.

Modifies:

• {S0, ...S15}: the state.

Steps:

The Diffuse Function The Diffuse function ensures full state mixing by performing 32 consecutive update operations, alternating between two input values. This function is critical for security during initialization and finalization phases, guaranteeing that every bit of the key and nonce influences the entire state, and that the authentication tag depends on all state bits. Inputs:

• x0: a 128-bit input value for even-numbered updates (updates 0, 2, 4, ..., 30).
• x1: a 128-bit input value for odd-numbered updates (updates 1, 3, 5, ..., 31).

Modifies:

• {S0, ...S15}: the state.

Steps:

Initialization and Processing Functions The following functions implement the high-level operations of HiAE: initialization, data absorption, encryption/decryption, and finalization.

The Init Function The Init function constructs the initial state {S0, ...S15} from the encryption key and nonce. The initialization process carefully distributes key material across the state and applies the Diffuse function to ensure all state bits are cryptographically mixed before processing begins. Inputs:

• key: the encryption key.
• nonce: the public nonce.

Defines:

• {S0, ...S15}: the initial state.

Steps:

The Absorb Function The Absorb function processes associated data by incorporating 128-bit blocks into the internal state. This function is used exclusively for authenticated data that should influence the authentication tag but not produce ciphertext output. Inputs:

• ai: the 128-bit input block.

Steps:

The Enc Function The Enc function encrypts a single 128-bit plaintext block. It serves as a simple wrapper around UpdateEnc, providing a clean interface for the block-by-block encryption process. Inputs:

• mi: the 128-bit input block.

Outputs:

• ci: the 128-bit encrypted block.

Steps:

The Dec Function The Dec function decrypts a single 128-bit ciphertext block. Like Enc, it provides a clean interface by wrapping the UpdateDec function. Inputs:

• ci: the 128-bit encrypted block.

Outputs:

• mi: the 128-bit decrypted block.

Steps:

The DecPartial Function The DecPartial function handles the special case of decrypting a partial block at the end of a ciphertext. This function carefully reconstructs the keystream to decrypt blocks smaller than 128 bits while maintaining the same state evolution as encryption. Inputs:

• cn: the encrypted input.

Outputs:

• mn: the decryption of cn.

Steps:

The Finalize Function The Finalize function completes the authentication process by generating a 128-bit tag. It incorporates the lengths of both the associated data and message (each encoded as 8 bytes in little-endian format), applies the Diffuse function for final mixing, and combines all state blocks to produce the authentication tag. 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:

Alternative Operating Modes While HiAE is primarily designed as an authenticated encryption algorithm, its flexible structure allows it to operate in two additional modes: as a stream cipher for keystream generation and as a message authentication code (MAC) for data authentication without encryption.

HiAE as a Stream Cipher The stream cipher mode of HiAE generates a keystream by encrypting an all-zero message. The Stream function expands a key and an optional nonce into a variable-length keystream. Security:

• When the nonce is fixed (including when using the default all-zeros nonce), a unique key MUST be used for each invocation to maintain security.

Inputs:

• len: the length of the keystream to generate in bits.
• key: the HiAE key.
• nonce: the HiAE nonce. If unspecified, it is set to N_MAX zero bytes.

Outputs:

• stream: the keystream.

Steps: This is equivalent to encrypting a message of len zero bits without associated data and discarding the authentication tag. Instead of relying on the generic Encrypt function, implementations can omit the Finalize function. After initialization, the Update function is called with constant parameters, allowing further optimizations.

HiAE as a Message Authentication Code In MAC mode, HiAE processes input data without generating ciphertext, producing only an authentication tag. This mode is useful when data authenticity is required without confidentiality. Note: Implementations of the Encrypt and Decrypt functions are not required to support MAC-only mode. This is an optional feature that can be implemented separately. Security:

• This is the only function that allows the reuse of (key, nonce) pairs with different inputs.
• HiAE-based MAC functions MUST NOT be used as hash functions: if the key is known, inputs causing state collisions can easily be crafted.
• Unlike hash-based MACs, tags MUST NOT be used for key derivation as there is no guarantee that they are uniformly random.

Inputs:

• data: the input data to authenticate (length MUST be less than or equal to A_MAX).
• key: the secret key.
• nonce: the public nonce.

Outputs:

• tag: the authentication tag.

Steps:

Security Considerations

Classic Setting HiAE provides 256-bit security against key recovery and state recovery attacks, along with 128-bit security for integrity against forgery attempts. Usage constraints:

• Tag truncation is not allowed. Implementations MUST use the full 128-bit authentication tag.
• A single key MUST NOT be used to protect more than 2⁶⁴ messages.
• For a given key, the nonce MUST NOT be reused under any circumstances (as specified in the Authenticated Encryption section).

It is important to note that the encryption security assumes the attacker cannot successfully forge messages through repeated trials . Regarding keystream bias attacks, analysis shows that at least 150-bit security is guaranteed by HiAE. Finally, HiAE is assumed to be secure against key-committing attacks at the birthday bound security level (64 bits), but it is not secure in the context-committing setting.

Quantum Setting HiAE targets a security strength of 128 bits against key recovery attacks and forgery attacks in the quantum setting. Security is not claimed against online superposition queries to cryptographic oracles, as such attacks are highly impractical in real-world applications.

Attack Considerations HiAE is assumed to be secure against the following attacks:

1. Key-Recovery Attack: 256-bit security against key recovery attacks.
2. Differential Attack: 256-bit security against differential attacks in the initialization phase.
3. Forgery Attack: 128-bit security against forgery attacks.
4. Integral Attack: Secure against integral attacks.
5. State-Recovery Attack:
   • Guess-and-Determine Attack: The time complexity of the guess-and-determine attack cannot be lower than 2²⁵⁶.
   • Algebraic Attack: The system of equations to recover HiAE states cannot be solved with time complexity lower than 2²⁵⁶.
6. Linear Bias: At least 150-bit security against statistical attacks.
7. Key-Committing Attacks: Secure in the FROB, CMT-1, and CMT-2 models at the birthday bound security level.
8. Context-Committing Attacks: Security is not claimed in the CMT-3 model.

The details of the cryptanalysis can be found in the paper .

Implementation Considerations HiAE is designed to balance the performance of XOR and AES instructions across both ARM and x86 architectures while being optimized to push performance to its limits. The algorithm’s XAXX structure enables platform-specific optimizations by exploiting the fundamental differences in how ARM and Intel processors implement AES round functions.

State Rotation Optimization Instead of performing physical rotations with the Rol() function, implementations can use a cycling index (offset) approach to avoid copying the entire 2048-bit state on every rotation. This optimization provides significant performance improvements across all platforms.

Cycling Index Approach The standard Rol() function requires copying all sixteen 128-bit blocks: This approach copies 2048 bits of data on every rotation. An optimized implementation can instead:

1. Keep the state blocks in a fixed array position
2. Maintain an offset variable tracking the logical position of S0
3. Map logical state block Si to physical position (i + offset) mod 16
4. Replace the entire Rol() operation with: offset = (offset + 1) mod 16

State Access Pattern With this optimization, the logical-to-physical state block mapping becomes:

• Logical S0 maps to physical position offset mod 16
• Logical S3 maps to physical position (3 + offset) mod 16
• Logical S9 maps to physical position (9 + offset) mod 16
• Logical S13 maps to physical position (13 + offset) mod 16

This approach is mathematically equivalent to the specification but eliminates the expensive memory operations associated with state rotation. Since Rol() is called in every Update(), UpdateEnc(), and UpdateDec() operation, this optimization provides substantial performance benefits during encryption and decryption operations.

Batch Processing Optimization Since the offset cycles back to zero every 16 operations (offset mod 16), implementations may benefit from processing data in batches of 16 blocks. After processing 16 consecutive input blocks, the logical state mapping returns to its original configuration, which can simplify implementation and potentially enable further optimizations such as loop unrolling or vectorization of the batch processing logic. When the offset is aligned to zero at the start of a batch, implementations can hardcode the specific offset values for each operation within the unrolled batch processing function, eliminating the need for modular arithmetic during the inner loop and providing additional performance benefits.

Platform-Specific Optimizations The key to HiAE’s cross-platform efficiency lies in understanding how different architectures implement AES operations. The following optimizations leverage architectural differences between ARM and Intel processors to maximize HiAE’s performance while maintaining cryptographic correctness.

ARM NEON Optimizations ARM processors with NEON SIMD extensions can efficiently compute AESL(x^y) and (with SHA3 extensions) three-way XOR operations. For convenience, the following additional primitives can be defined:

• XAESL(x, y): Computes AESL(x^y) in a single fused operation (assembly instruction AESE ∘ AESMC, or equivalently C intrinsic vaesmcq_u8(vaeseq_u8(x, y)))
• XOR3(x, y, z): Computes x^y^z in a single three-way XOR instruction (assembly instruction EOR3, or equivalently C intrinsic veor3q_u8(x, y, z))

ARM-Optimized Update Function Original implementation: ARM-optimized implementation:

ARM-Optimized UpdateEnc Function Original implementation: ARM-optimized implementation:

ARM-Optimized UpdateDec Function Original implementation: ARM-optimized implementation:

ARM-Optimized DecPartial Function Original implementation: ARM-optimized implementation:

Intel AES-NI Optimizations Intel processors with AES-NI can efficiently compute AESL(y)^z patterns. We can define the following additional function:

• AESLX(y, z): Computes AESL(y) ^ z using a single instruction (assembly instruction AESENC, or equivalently C intrinsic _mm_aesenc_si128(y, z))

Intel-Optimized Update Function Original implementation: Intel-optimized implementation:

Intel-Optimized UpdateEnc Function Original implementation: Intel-optimized implementation:

Intel-Optimized UpdateDec Function Original implementation: Intel-optimized implementation:

Intel-Optimized DecPartial Function Original implementation: Intel-optimized implementation:

Decryption Performance It is expected that HiAE decryption will be slower than encryption due to inherent data dependencies in the algorithm. While encryption can process keystream generation and state updates in parallel, decryption must first recover the plaintext before performing any state updates. This sequential dependency chain is a consequence of HiAE’s design, which incorporates plaintext into the internal state to provide strong authentication properties.

Security Considerations for Implementations The security of HiAE against timing and physical attacks is limited by the implementation of the underlying AESL function. Failure to implement AESL 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 depend on the threat model in question. When implementing the platform-specific optimizations described above, care must be taken to ensure that:

• All operations complete in constant time
• No secret-dependent memory accesses occur
• The optimization does not introduce timing variations based on input data

Validation A complete list of known implementations and integrations is available at https://github.com/hiae-aead/draft-pham-hiae, including reference implementations. A comprehensive comparison of HiAE’s performance with other high-throughput authenticated encryption schemes on ARM and x86 architectures is also provided, demonstrating the effectiveness of these platform-specific optimizations.

IANA Considerations IANA is requested to register the following entry in the AEAD Algorithms Registry:

Algorithm Name	ID
AEAD_HIAE

References Normative References National Institute of Standards and Technology (NIST) Federal Information Processing Standards Publication 197, Update 1 Fastly Inc. Individual Contributor This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance 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 This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-aegis-aead. 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. 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. 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 application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] Informative References Computer Security – ESORICS 2023 Ericsson Research Lund University Ericsson Research Ericsson Research IACR Transactions on Symmetric Cryptology, 2019(3) Intel Corporation Huawei International Pte., Ltd. Huawei International Pte., Ltd. Huawei International Pte., Ltd. Huawei International Pte., Ltd. Cryptology ePrint Archive, Paper 2025/377 Huawei International Pte., Ltd. Huawei International Pte., Ltd. Huawei International Pte., Ltd. Huawei International Pte., Ltd. Cryptology ePrint Archive, Paper 2025/1235

Test Vectors

Test Vector 1 - Empty plaintext, no AD

Test Vector 2 - Single block plaintext, no AD

Test Vector 3 - Empty plaintext with AD

Test Vector 4 - Rate-aligned plaintext (256 bytes)

Test Vector 5 - Rate + 1 byte plaintext

Test Vector 6 - Rate - 1 byte plaintext

Test Vector 7 - Medium plaintext with AD

Test Vector 8 - Single byte plaintext

Test Vector 9 - Two blocks plaintext

Test Vector 10 - All zeros plaintext

Test Vector 11 - Partial-block AD (padding demonstration) This test vector specifically demonstrates the padding behavior when associated data length is not a multiple of the block size (128 bits). The AD is 13 bytes (104 bits), which requires 3 bytes (24 bits) of zero padding to reach the next block boundary.

Function-by-Function Example This appendix provides step-by-step examples of HiAE internal functions for implementers. All values are in hexadecimal. The examples use the following test data:

• Key: 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
• Nonce: 00112233445566778899aabbccddeeff
• AD: 48656c6c6f (5 bytes: “Hello”)
• Msg: 576f726c64 (5 bytes: “World”)

AESL Function Example The AESL function performs a single AES encryption round with a zero round key.

Initialize Function Example The Initialize function sets up the initial state from the key and nonce.

Update Function Example The Update function modifies the internal state with an input block.

Enc Function Example The Enc function encrypts a single message block.

Finalize Function Example The Finalize function produces the authentication tag.

Complete Encryption Example

Acknowledgments The HiAE algorithm leverages the AES permutation invented by Joan Daemen and Vincent Rijmen. We would like to thank Samuel Lucas for his review of the draft.