The Fast Software Authenticated Encryption HiAE

Introduction Many recent cryptographic designs have utilized SIMD instructions to achieve high performance, particularly on x86 platforms using AES-NI . AES-NI has become the foundation for many recent high-speed (authenticated) encryption algorithms like AEGIS , SNOW-V , and Rocca-S , which are tailored to take advantage of the parallelism and efficiency offered by these instructions. However, these designs often neglect the architectural differences between x86 and ARM, where SIMD instructions are implemented via NEON rather than AES-NI. This oversight results in inconsistent performance when deploying these algorithms on ARM-based devices, which dominate mobile and embedded systems. The transition to 6G, with its demand for ultra-high data rates and reliance on software-defined networks (SDN) or Cloud Radio Access Networks (Cloud RAN), further emphasizes the need for cryptographic algorithms optimized for diverse platforms. While some existing designs achieve remarkable performance on x86—reaching or exceeding 100 Gbps—these same algorithms often perform suboptimally on ARM platforms due to differences in SIMD instruction sets and hardware support for AES round functions. This gap highlights the pressing need for a unified approach that ensures high and consistent performance across both architectures. Addressing this challenge requires rethinking cryptographic design to leverage the unique capabilities of each platform while maintaining compatibility and efficiency. This motivates our work in developing a cross-platform cryptographic HiAE that achieves competitive performance on both x86 and ARM architectures, meeting the stringent demands of 6G systems.

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

Notations AESL(x): AESL(x) = MixColumns o SubBytes o ShiftRows(x), of AES operations .
a ^ b: The bitwise exclusive OR operation between a and b.
S: The internal state, composed of 16 blocks, i.e. S = (S[0], S[1], ..., S[15]), where S[i] (0 <= i <= 15) are blocks and S[0] is the first block. The i-th state block at round r is defined as S^r[i].
N: A 128-bit nonce.
AD_i: A 128-bit associated data block.
M_i: A 128-bit message block.
C_i: A 128-bit ciphertext block.
const_0: A 128-bit constant, represented in hexadecimal as 0x3243f6a8885a308d313198a2e0370734.
const_1: A 128-bit constant, represented in hexadecimal as 0x4a4093822299f31d0082efa98ec4e6c8.
X || 0^*: A 128-bit block string of the concatenation of X and the complement of zeros.
|M|: the length in bit of the string M.
Truncate(x, l): Output the upper bits of x with length l.

The Round Function The input of the round function UpdateFunction(S,X) of HiAE consists of the state S and a data block X. If denoting the output by Snew, Snew:=UpdateFunction(S,X) can be defined as follows:

Algorithm Description In this section, we describe the specification of our design.

Specification HiAE is structured into four phases: initialization, processing of associated data, encryption, and finalization. HiAE has a 2048-bit state, made of sixteen 128-bit blocks S_0||S_1||...||S_{15}. The parameters for this algorithm, that are consistent with the definition in , Section 4, are defined as:

K_LEN (key length): 32 bytes (256 bits).
P_MAX (maximum length of the plaintext): 2^61 - 1 bytes (2^64 - 8 bits).
A_MAX (maximum length of the associated data): 2^61 - 1 bytes (2^64 - 8 bits).
N_MIN (minimum nonce lentgh) = N_MAX (maximum nonce length) = 16 bytes (128 bits).
C_MAX (maximum ciphertext length) = P_MAX + tag length = (2^61 - 1) + 16 bytes (2^64 - 8 + 128 bits).

In more details, HiAE takes as input a 256-bit key K = K_0||K_1, a 128-bit nounce N, the associated data AD, and the message M.
The output includes the ciphertext C where |C| = |M| and a 128-bit tag T. Initially, AD and M are padded with 0 to ensure their lengths are multiples of 128 as Pad(AD) = AD||0* = AD_0|| ... || AD_{|AD|/128-1} and Pad(M) = M||0* = M_0|| ... || M_{|M|/128-1}.
The encryption and authentication process are described below.

Initialization First, the state is loaded with (N, K_0, K_1) as follow: Next, the state is updated with 32 UpdateFunction(S, const_0), then XORed with the key one more:

Processing the Associated Data Following initialization, the associated data AD is used to update the state as: This phase is skipped if the associated data is empty.

Encryption At each step of the encryption, a 128-bit message block is used to update the state, and M_i is then encrypted to produce C_i following, and skipped the phase if the message is empty.

Finalization After encrypting all the message blocks, the state is updated again with the lengths of associated data and message as: then the authentication tag is generated as:

HiAE Algorithm A pseudo algorithm of HiAE is described in the following.

Settings Specifications

Authenticated Encryption Encrypt(msg, ad, key, nonce) The Encrypt function encrypts a message and returns the ciphertext along with an authentication tag that confirms the integrity and authenticity of both the message and any associated data, if present. Security:

For a specific key, the nonce MUST NEVER be reused under any circumstances, as doing so could enable an attacker to reconstruct the internal state.
The key MUST be selected randomly from a uniform distribution.

Inputs:

msg: the message to be encrypted (its length MUST not exceed P_MAX).
ad: the associated data to authenticate (its length MUST not exceed A_MAX).
key: the encryption key (256 bits).
nonce: the public nonce.

Outputs:

ct: the ciphertext.
tag: the authentication tag.

Process:

Authenticated Decryption Decrypt(ct, tag, ad, key, nonce) The Decrypt function decrypts the ciphertext, checks the validity of the authentication tag, and returns the message if the tag is verified successfully, or an error if the tag verification fails. Security:

If tag verification fails, the scheme MUST NOT output the decrypted ciphertext.

Inputs:

ct: the ciphertext to decrypt (its length MUST NOT exceed C_MAX).
tag: the authentication tag.
ad: the associated data to authenticate (its length MUST NOT exceed 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 provided inputs.

Process:

Setting as a Stream Cipher Keystream(len, key, nonce) The Stream function generates a keystream of variable length by expanding a key and, optionally, a nonce. Inputs:

len: Desired length of the keystream in bits.
key: The HiAE encryption key.
nonce: The HiAE nonce. If not provided, it defaults to N_MAX bytes of zeros.

Outputs:

keystream: The resulting keystream.

Process: The process of generating the keystream is equivalent to encrypting a zero-filled message of length len.

Setting as a Message Authentication Code HiAE can also be used to construct a Message Authentication Code (MAC), taking a key, nonce, and data as input, and producing a 128-bit authentication tag as output. Mac(data, key, nonce) Security:

This is the only function where reusing the same (key, nonce) pair with different input data is permitted.
HiAE-based MACs MUST NOT be used as hash functions, as a known key allows for easy construction of inputs that cause state collisions.
Unlike MACs built on cryptographic hashes, HiAE-generated tags MUST NOT be used for key derivation, since they are not guaranteed to be uniformly random.

Inputs:

data: The data to be authenticated (MUST NOT exceed A_MAX in length).
key: The secret key.
nonce: The public nonce.

Output:

tag: The resulting authentication tag.

Process:

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. It is important to note that the encryption security assumes the attacker cannot successfully forge messages through repeated trials.
Related to the keystream bias attacks, our analysis shows that at least 150-bit security is guaranteed by HiAE.
Finally, we claim that HiAE is secure in the key-commiting attacks, and we do not claim its security in the everything-commiting setting.

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

Attacks Considerations HiAE is secure against the following attacks: The details of the crytanalysis can be found in the paper .

Implementation Consideration HiAE is designed to balance the performance of XOR and AES-NI instructions across both ARM and x86 architectures, while being optimized to push performance to its limits. A complete list of known implementations and integrations is available at https://github.com/Concyclics/HiAE, including reference implementations of HiAE as AEAD Encryption and Decryption, and HiAE-MAC. A comprehensive comparison of HiAE's performance with other high-throughput authenticated encryption schemes on ARM and x86 architectures is also provided.

IANA Considerations TBD.

Test Vectors

Test Vector 1

Test Vector 2

Test Vector 3

Test Vector 4

Test Vector 5

Test Vector 6

Test Vector 7

Test Vector 8

Test Vector 9

Test Vector 10