Side-Channel Protected Hardware Design of Ascon-128 and Ascon-Hash (v1.2)

Ascon is a family of authenticated encryption and hashing algorithms designed to be lightweight and easy to implement, even with added countermeasures against side-channel attacks. Ascon has been selected as new standard for lightweight cryptography in the NIST Lightweight Cryptography competition (2019–2023). Ascon has also been selected as the primary choice for lightweight authenticated encryption in the final portfolio of the CAESAR competition (2014-2019).

This verilog implementation of Ascon is based off of the Verilog Ascon implementation by Robert Primas. The verilog version uses a simpler interface that considerably reduces the size of the code base. The main interface changes are:

• t-order protection via NUM_SHARES paramater
• Some signals have been removed (see Interface section).
• Bus width is fixed to 32*NUM_SHARES bits.
• Padding of inputs/outputs is shifted to software.

Besides the interface changes, this code base comes with:

• A more permissive CC0 license.
• A low amount of external dependencies, i.e., Python, Verilator, and optionally GTKWave.
• Easy instructions for simulation/debugging using open-source tools.

Available Variants

• v1
  • Ascon-128 + Ascon-Hash.
  • 32-bit block data interface.
  • 1 permutation round per clock cycle.
• v2
  • Ascon-128 + Ascon-Hash.
  • 32-bit block data interface.
  • 2 permutation rounds per clock cycle.
• v3
  • Ascon-128 + Ascon-Hash.
  • 32-bit block data interface.
  • 3 permutation rounds per clock cycle.
• v4
  • Ascon-128 + Ascon-Hash.
  • 32-bit block data interface.
  • 6 permutation rounds per clock cycle.

Files

• rtl/ascon_core.sv: Verilog implementation of the Ascon core.
• rtl/asconp.sv: Verilog implementation of the Ascon permutation.
• rtl/config_core.sv: Configuration file for the Ascon core and test bench.
• rtl/config_v*.sv: Configuration files for the Ascon core.
• rtl/tb.sv: Verilog test bench for the Ascon core.
• tv/*: Test vector files for the verilog test bench.
• LICENSE: License file.
• Makefile: Commands for running verilog test bench and optionally showing wave forms in GTKWave.
• README.md: This README.
• ascon.py: Python software implementation of Ascon, used by run_tb.py.
• config.gtkw: Optional configuration file for the GTKWave waveform viewer.
• run_tb.py: Python script for running Ascon in both verilog/python and comparing the results.

Interface

The interface of the Ascon core is similar to GMU's crypto core interface (Figure 5.1) that was often used during the NIST standardization for lightweight authenticated encryption. The following changes to the GMU crypto core interface were made:

• Removed signals:
  • bdi_valid_bytes, bdi_pad_loc, bdi_size
  • fdi_ready, fdi_valid, fdi_data
  • fdo_ready, fdo_valid, fdo_data
  • bdo_valid_bytes, end_of_block, key_update
• Renamed signals:
  • decrypt_in -> decrypt
  • hash_in -> hash
  • msg_auth, msg_auth_valid, msg_auth_ready -> auth, auth_valid, auth_ready

The resulting (simplified) interface of the Ascon core is shown here:

The following table contains a description of the interface signals:

Name	Description
clk	Clock signal.
rst	Reset signal. Note: Synchronous active high.
key	Key data input.
key_valid	Key data is valid.
key_ready	Ascon core is ready to receive a new key.
bdi_data	Block data input (BDI).
bdi_valid	BDI data is valid.
bdi_ready	Ascon core is ready to receive data.
bdi_eot	The current BDI block is the last block of its type.
bdi_eoi	The current BDI block is the last block of input other than the tag segment.
bdi_type	Type of BDI data. See rtl/config_core.sv.
decrypt	0=Encryption, 1=Decryption.
hash	0=Encryption/Decryption, 1=Hash.
bdo_data	Block data output (BDO).
bdo_valid	BDO data is valid.
bdo_ready	Test bench is ready to receive data.
bdo_type	Type of BDO data. See rtl/config_core.sv.
auth	1=Authentication success, 0=Authentication failure.
auth_valid	Authentication output is valid.
auth_ready	Test bench is ready to accept authentication result.

You can have a look at rtl/tb.sv for an example of how the Ascon core interface can be used.

Quick Start

• Install the Icarus Verilog (iverilog) open-source verilog simulator:
  • See https://steveicarus.github.io/iverilog/usage/installation.html.
  • Tested with version 12.0 and flags -g2005-sv, -g2009, and -g2012.
• Execute verilog test bench:
  • make
  • Runs rtl/tb.sv using the v1 variant of the Ascon core and tv/tv.txt as input.
  • For other variants use make v2 etc..
• Execute verilog test bench and show resulting wave forms:
  • make wave
  • Same as make but also opens the resulting tb.vcd in GTKWave.
  • For other variants use make v2_wave etc..

Automatic Generation and Execution of Test Vectors

• python run_tb.py -s
  • Generate a new tv/tv.txt, run rtl/tb.sv using v1 of the Ascon core, and compare output to the Ascon software implementation in ascon.py.
  • For other variants add -v 2 etc..
• python run_tb.py -w
  • Same as python run_tb.py -s except the entire process is repeated for many inputs with different lengths.
  • For other variants add -v 2 etc..

Contact

• Rishub Nagpal (rishub.nagpal 'at' iaik.tugraz.at)

Acknowledgements

The interface of the Ascon core is inspired by the LWC Hardware API Development Package that was mainly developed by the Cryptographic Engineering Research Group at George Mason University (GMU).