Efficient Hardware Accelerator for AEGIS-128 Authenticated Encryption

Abstract

Security of transaction is of paramount importance in modern world of ubiquitous computing and data movement. To provide a framework of standard authenticated encryption techniques, CAESAR contest has been announced recently. Multiple entries in this contest are based on AES, which has been also, a popular choice as a primitive for authenticated encryption in the past. In this paper, we perform in-depth study of efficient hardware implementation for AES-based AEGIS-128 authenticated encryption, a prominent entry in the CAESAR contest. Through a complete study of possible throughput-area improvement techniques, we report multiple design points ranging from a high throughput of $121.07$ Gbps design to a low-area implementation of $18.72$ KGE, using commercial synthesis flows and 65 nm ASIC technology. We believe our results will serve as important design metric for the CAESAR contest as well as for efficient AEGIS-128 deployment.

A AEGIS-128

We briefly describe the AEGIS-128 algorithm [19]. AEGIS-128 uses a 128-bit key and 128-bit initialization vector to encrypt and authenticate a message. The associated data length and plain text length are less than $2^{64}$ bits. The authentication tag length is less than or equal to 128-bits. The use of 128-bit tag length is strongly recommended.

The state update function StateUpdate128 of AEGIS-128 updates a 80-byte state $S_i$ using a 16-byte message block $m_i$. StateUpdate128 is stated in Algorithm 1. The block diagram of StateUpdate128 function is shown in Fig. 1. The function Round is an AES encryption round as shown in Fig. 11.

Fig. 11.

Round function used by StateUpdate128

1.1 A.1 Encryption and Generation of Tag of AEGIS-128

AEGIS-128 has $4$ phases for encryption. We describe each phase concisely. We use the same notations that are defined in the original paper with the description of AEGIS-128 [19].

• 1 Initialization of AEGIS-128

  Initialization of AEGIS-128 consists of loading the key and IV into the state, and running the cipher for 10 steps with the key and IV being used as message.

  

• 2 Processing the Authenticated Data

  The associated data AD is used to update the state. If the last associated data block is not a full block, use 0 bits to pad it to 128 bits, and the padded full block is used to update the state. Note that if adlen = 0, the state will not be updated.

  

• 3 Encryption of Plaintext Data

  If the last plaintext block is not a full block, use 0 bits to pad it to 128 bits, and the padded full block is used to update the state. But only the partial block is encrypted. Note that if msglen = 0, the state will not get updated, and there is no encryption.

  

• 4 Finalization

  After encrypting all the plaintext blocks, we generate the authentication tag using seven more steps. The length of the associated data and the length of the message are used to update the state.

  

  The authentication tag $T$ consists of the first $t$ bits of $T'$.

1.2 A.2 Decryption and Verification of AEGIS-128

The exact values of key size, IV, size, and tag-size should be known to the decryption and verification processes. The decryption starts with the initialization and the processing of authenticated data. Then the ciphertext is decrypted as follows:

• If the last ciphertext block is not a full block, decrypt only the partial ciphertext block. The partial plaintext block is padded with 0 bits, and the padded full plaintext block is used to update the state.

• For $i= 0$ to $v-1$, Perform decryption and update the state.

The finalization in the decryption process is the same as that in the encryption process. It is emphasized that if the verification fails, the ciphertext and the newly generated authentication tag should not be given as output; otherwise, the state of AEGIS-128 is vulnerable to known-plaintext or chosen-ciphertext attacks (using a fixed IV).