ASCON Suite
Synthetic Initialization Vector (SIV) mode for ASCON

Why SIV?

This library provides support for SIV mode (Synthetic Initialization Vector). SIV mode authenticates the associated data and the plaintext before encrypting the plaintext.

The SIV construction makes the result resistant against reuse of the nonce as long as the combination of the associated data and plaintext is unique. If the combination is not unique, then the algorithm leaks that the same plaintext has been encrypted again but does not reveal the plaintext itself.

SIV mode can be useful when encrypting other keys for transport or storage under a passphrase. If multiple keys are encrypted with a regular AEAD scheme and the same passphrase and nonce, then the result will be insecure. SIV mode is safer for this use case; even a single bit change in the plaintext will cause massive changes in the SIV-encrypted output.

There are three SIV modes implemented by the library: ASCON-128-SIV, ASCON-128a-SIV, and ASCON-80pq-SIV. Each of these is based on the corresponding standard AEAD modes.

ASCON SIV modes increase the size of the plaintext by 16 bytes, which provides the authentication tag. The tag must not be discarded because the data cannot be successfully decrypted without it.

SIV mode overview

The SIV mode here is inspired by some of the non-ASCON candidates to the second round of the NIST lightweight cryptography competition; notably ESTATE, Romulus-M, and SUNDAE-GIFT.

In each case, the algorithm first authenticates the associated data and plaintext with the key and nonce. The resulting authentication tag is used as a new nonce with the original key to encrypt the plaintext. This requires two passes over the plaintext, compared with only one pass for the regular ASCON AEAD modes like ASCON-128.

On the decryption side, the authentication tag is used as a nonce to decrypt the ciphertext. Then the authentication tag is recomputed over the associated data and plaintext to verify authenticity.

Technical details for ASCON-128-SIV

This section describes the authenticated encryption mode ASCON-128-SIV. ASCON-128a-SIV and ASCON-80pq-SIV are constructed in a similar manner.

The single-pass ASCON-128 AEAD mode is restructured into a two-pass form as shown in the diagram below. The first pass of SIV encryption is identical to the regular AEAD mode, but with the ciphertext discarded.

The second pass re-initializes the state with the original key K and the authentication tag T as the nonce. The ASCON permutation is operated in a simple Output FeedBack (OFB) mode to encrypt the plaintext.

Here:

  • IV1 and IV2 are initialization vectors for the two phases.
  • K is the 128-bit key.
  • N is the 128-bit nonce for the authentication phase.
  • A1 .. As are the padded blocks of the associated data.
  • P1 .. Pt are the padded blocks of the plaintext data.
  • C1 .. Ct are the blocks of ciphertext output.
  • T is the 128-bit authentication tag and the nonce for the encryption phase.
  • pa is the ASCON permutation with a rounds (12 in the case of ASCON-128-SIV, ASCON-128a-SIV, and ASCON-80pq-SIV).
  • pb is the ASCON permutation with b rounds (6 in the case of ASCON-128-SIV and ASCON-80pq-SIV and 8 in the case of ASCON-128a-SIV).

Authentication

The authentication phase is identical to the regular ASCON-128 mode, with a slight modification to the initialization vector (IV).

The 320-bit ASCON permutation state is initialized with a concatenation of the following:

  • 64-bit initialization vector (IV) 0x81400c0600000000
  • 128-bit key
  • 128-bit nonce

Note that the IV is the ASCON-128 value 0x80400c0600000000 with 0x81 in the key length position instead of 0x80. This provides domain separation with the regular ASCON-128 AEAD mode.

Apply the ASCON permutation with 12 rounds and then XOR the key with the trailing 128 bits of the state.

If the associated data is non-zero in length, then add a 1 bit and enough zero bits to make the result a mulitple of 8 bytes in length. Absorb this into the ASCON permutation state in the same way as ASCON-128; for each 8 byte block:

  • XOR the 8 bytes of input with the first 8 bytes of the permutation state.
  • Apply the ASCON permutation with 6 rounds.

Next, XOR a 1 with the last bit of the ASCON permutation state to provide separation between the associated data and plaintext.

Add a 1 bit to the plaintext and enough zero bits to make the result a multiple of 8 bytes in length. Absorb the padded plaintext data in the same way as the associated data.

Finally, generate the 128-bit authentication tag as follows:

  • XOR the 128 bits of the key into the ASCON permutation state starting at byte offset 8.
  • Apply the ASCON permutation with 12 rounds.
  • XOR the 128 bits of the key with the ASCON permutation state starting at byte offset 24 to generate the 128 bits of the authentication tag.

Encryption

To encrypt the plaintext, the 320-bit ASCON permutation state is re-initialized with a concatenation of the following:

  • 64-bit initialization vector (IV) 0x82400c0600000000
  • 128-bit key
  • 128-bit authentication tag from the previous step

Note that the IV is the ASCON-128 value 0x80400c0600000000 with 0x82 in the key length position instead of 0x80. This provides domain separation with the regular ASCON-128 AEAD mode and with the SIV authentication phase.

Apply the ASCON permutation with 12 rounds and then XOR the key with the trailing 128 bits of the state.

Encryption uses the ASCON permutation in Output Feedback (OFB) mode to generate a keystream to XOR against the plaintext to produce the ciphertext. The same code can also be used for decryption.

For each 8-byte block of plaintext:

  • XOR the next 8 bytes of plaintext with the first 8 bytes of the permutation state to produce the next 8 bytes of ciphertext.
  • Apply the ASCON permutation with 6 rounds (note that we do not XOR the plaintext into the permutation state this time).

If the final block does not have a full 8 bytes, then it is XOR'ed with the first n bytes of the state where n is the size of the partial block. Unlike in the authentication phase, no 1-bit padding is performed.

Variants

ASCON-128a-SIV and ASCON-80pq-SIV are defined in a similar way using the same offsets and round counts as the corresponding regular mode. The complete list of initialization vectors is:

  • ASCON-128 regular IV: 0x80400c0600000000
  • ASCON-128-SIV authentication phase IV: 0x81400c0600000000
  • ASCON-128-SIV encryption phase IV: 0x82400c0600000000
  • ASCON-128a regular IV: 0x80800c0800000000
  • ASCON-128a-SIV authentication phase IV: 0x81800c0800000000
  • ASCON-128a-SIV encryption phase IV: 0x82800c0800000000
  • ASCON-80pq regular IV: 0xa0400c06
  • ASCON-80pq-SIV authentication phase: 0xa1400c06
  • ASCON-80pq-SIV encryption phase: 0xa2400c06

The key lengths in the ASCON-128 and ASCON-128a initialization vectors are 129 and 130. In theory this would conflict with a future standard AEAD mode with 129-bit and 130-bit keys. But such key lengths are highly unlikely. Similarly for the 161-bit and 162-bit key lengths of ASCON-80pq-SIV.

Test vectors

The repository contains Known Answer Test (KAT) vectors for ASCON-128-SIV, ASCON-128a-SIV, and ASCON-80pq-SIV in the "test/kat" directory. The vectors were generated with a slightly modified version of the ASCON reference code which can be provided upon request.