Skip to content

Latest commit

 

History

History
325 lines (252 loc) · 15.2 KB

README.md

File metadata and controls

325 lines (252 loc) · 15.2 KB
Raw

RISC-V ISEs for NIST LWC submissions

The NIST lightweight cryptography process is an attempt to "solicit, evaluate, and standardize lightweight cryptographic algorithms that are suitable for use in constrained environments". From an initial 57 submissions, 10 final-round candidates were selected. The lwise project and repo. capture an exploration of Instruction Set Extensions (ISEs) for (a subset of) these candidates, based on the use of RISC-V: the goal is to add understanding to and so inform selection of any resulting standard, with respect to implementation-related criteria such as execution latency.

Overview

  • We consider the RISC-V baseline ISA as being rv32gc_Zbkb_Zbkx in the 32-bit case or rv64gc_Zbkb_Zbkb in the 64-bit case, meaning that the following standard extensions

    • M (multiplication)
    • A (atomic)
    • F (single-precision floating-point)
    • D (double-precision floating-point)
    • C (compressed)
    • Zbkb (a subset of K: bit manipulation instructions for cryptography)
    • Zbkx (a subset of K: crossbar permutation instructions)

    are available by default.

  • Our strategy for each candidate is roughly

    1. do some (manual) analysis,
    2. produce an ISE design (including instruction semantics, encoding, and so on),
    3. develop a simulator-supported implementation of the ISE,
    4. develop an ISE-assisted software implementation,
    5. develop a hardware-supported implementation of the ISE,

    with progress so far summarised as follows

    Algorithm Identifier Design Encoding Toolchain Software Hardware
    Ascon ascon o o o o o
    Elephant elephant o o o o o
    GIFT-COFB gift o o o o o
    Grain128-AEAD grain o o o o o
    ISAP isap o o o o o
    PHOTON-Beetle photon o o o o o
    Romulus romulus o o o o o
    Schwaemm and Esch sparkle o o o o o
    TinyJAMBU jambu o o o o o
    Xoodyak xoodyak o o o o o

    noting that we ignore ISAP because it uses building blocks (e.g., the Ascon permutation) already covered by other candidates.

Organisation

├── bin                     - scripts (e.g., environment configuration)
├── bitstream               - pre-built bitstreams for the arty100T board 
├── build                   - working directory for build
├── doc                     - documentation
└── src                     - source code
    ├── hw                    - source code for hardware
    │   ├── fpga                - source code for the FPGA implementation using Vivado
    │   │   ├── board             - source for supporting a specific board (e.g., sakura-x)
    │   │   ├── script            - scripts for handling the FPGA bitstream on Vivado
    │   │   ├── soc               - the Vivado projects based on the Rocket Chip SoC.
    │   │   └── software          - build algorithm-specific sofware running on the FPGA.
    │   ├── rocketchip          - source code for ISE-enabled Rocket Chip
    │   ├── rtl                 - rtl implementation
    │   │   ├── rv32              - 32-bit implementation
    │   │   └── rv64              - 64-bit implementation
    │   ├── verilator         - source code for emulator for use with Rocket Chip
    │   └── yosys_synth       - synthesise hardware implementation using yosys
    ├── hw-toolchain        - source code for hardware toolchain
    │
    ├── sw                  - source code for software
    │   ├── ${ALG}              - anything algorithm-specific
    │   │   ├── nist              - NIST submission content
    │   │   ├── arch              -   architecture-specific resources
    │   │   │   ├── generic         - generic, i.e., vanilla C
    │   │   │   ├── rv32            - 32-bit RISC-V
    │   │   │   └── rv64            - 64-bit RISC-V
    │   │   └── imp               - implementation-specific resources
    │   │       ├── generic         - generic, i.e., vanilla C
    │   │       ├── rv32            - 32-bit RISC-V
    │   │       └── rv64            - 64-bit RISC-V
    │   └── share               - anything algorithm-agnostic
    │       ├── nist              - NIST submission content
    │       └── arch              -   architecture-specific resources
    │           ├── generic         - generic, i.e., vanilla C
    │           ├── rv32            - 32-bit RISC-V
    │           └── rv64            - 64-bit RISC-V
    └── sw-toolchain        - source code for software tool-chain

Notes: software

Build system

  • The build system is controlled by several environment variables:

    • ${ALG}

      • role: specifies the algorithm, i.e., select ${REPO_HOME}/src/sw/${ALG}
      • values: ascon, elephant, gift, grain, isap, photon, romulus, jambu, sparkle, xoodyak
      • default: sparkle

    • ${API}

      • role: specifies the API, i.e., the functionality and so interface supported
      • values: aead, hash
      • default: aead

    • ${ARCH}

      • role: specifies the architecture, i.e., select ${REPO_HOME}/src/sw/${ALG}/arch/${ARCH}
      • values: generic, rv32, rv64
      • default: generic

    • ${IMP}

      • role: specifies the implementation, e.g., select ${REPO_HOME}/src/sw/${ALG}/nist or ${REPO_HOME}/src/sw/${ALG}/imp/${IMP}
      • values: nist, generic, rv32, rv64
      • default: nist

  • The ${CONF} environment variable allows options to be passed to GCC, e.g.,

    Symbol Meaning
    DRIVER_RANDOM use /dev/random as a source of randomness (rather than rand)
    DRIVER_TRIALS_WARM number of trials performed by the driver during "warm-up" (i.e., non-measured) phase (default is 10)
    DRIVER_TRIALS_REAL number of trials performed by the driver during "real" (i.e., measured) phase (default is 1000)
    DRIVER_BYPASS_TEST bypass the driver phase for verification, e.g., vs. the KAT material
    DRIVER_BYPASS_TIME bypass the driver phase for evaluation, i.e., measurement of execution latency
    DRIVER_SIZEOF_A number of bytes in a, i.e., additional data (default is 16)
    DRIVER_SIZEOF_M number of bytes in m, i.e., plaintext data (default is 16)

    plus various algorithm-, architecture-, and/or implementation-specific cases documented elsewhere.

Toolchain

  • Options which use a RISC-V baseline ISA plus custom ISE do so via the .insn directive, rather than an invasive change to binutils itself.

  • Fix paths, e.g.,

    export RISCV="/opt/riscv"

  • Build a multi-architecture tool-chain into ${RISCV}:

    git clone https://github.com/riscv/riscv-gnu-toolchain.git ./riscv-gnu-toolchain
cd ./riscv-gnu-toolchain
git submodule update --init --recursive
./configure --prefix="${RISCV}" --enable-multilib --with-multilib-generator="rv32gc-ilp32--;rv64gc-lp64--"
make

  • Clone the repo.

    git clone https://github.com/scarv/lwise.git ./lwise
cd ./lwise
git submodule update --init --recursive
source ./bin/conf.sh

  • Build an ISE-enabled spike and associated pk for each algorithm, e.g.,

    make ALG="sparkle" sw-toolchain-build

  • Build and execute implementation, e.g.,

    make ALG="sparkle" sw-build
make ALG="sparkle" sw-run

    or use the script provided, e.g.,

    make ALG="sparkle" sw-scan

    to automatically scan through various different configurations (such as those with respect to ISEs options, unrolling strategies, and so on).

  • Note that since the tool-chain is patch-based, making changes to it is somewhat tricky. The idea, for each component, (i.e., pk and spike) referred to as ${COMPONENT} is as follows:

    • perform a fresh clone of the component repository,
    • apply the existing patch to the cloned component repository,
    • implement the change in the cloned component repository,
    • stage the change via git add, but do not commit it, in the cloned component repository,
    • execute ${REPO_HOME}/src/sw-toolchain/${COMPONENT}-update.sh to produce an updated patch,
    • optionally commit and push the updated patch.

Notes: hardware

Build system

  • ISE supporting hardware is implemented in Verilog and integrated into a Rocket Chip. The built hardware system is controlled by two environment variables, namely ${BOARD} and ${ARCH}.

    • The base Rocket Chip can be configured with a 32-bit or 64-bit architecture (i.e., ARCH=rv32 or ARCH=rv64, respectively). ${ARCH} is consistent with the build software system.
    • The hardware system is synthesized targeting to two supported boards (i.e., BOARD=arty100T or BOARD="sakura-x"). Only the pre-built bitstreams for the arty100T board are provided in this Repos.

Toolchain

  • Fix paths for the Rocket Chip toolchain, e.g.,

    export RISCV_ROCKET="/opt/riscv-rocket"

  • Build a toolchain for use with Rocket-Chip into ${RISCV_ROCKET}:

    make hw-toolchain-build

  • The build system in

    ${REPO_HOME}/src/hw/Makefile

    includes

    • ISE-enabled Rocket Chip implementation,
    • an FPGA implementation using Vivado,
    • an emulator for the implementation.

  • Get an ISE-enabled Rocket-Chip implementation

    export ROCKETCHIP_REPO=${REPO_HOME}/build/rocketchip
make hw-get-rocketchip

  • Fix path for the installed Vivado Design Suite, e.g.,

    export VIVADO_TOOL_DIR="/opt/Xilinx/Vivado/2019.1"
source ./bin/Vivado-conf.sh

  • Run a software on FPGA implemetation with a pre-built bitstream:

    • Connect the arty100T board to a Computer via a USB port. Assumingly, the port /dev/ttyUSB0 is used.
    • Build and execute implementation on the Arty100T, e.g.,
    PORT="/dev/ttyUSB0" BOARD="arty100T" ALG="sparkle" ARCH="rv32" make fpga-run
    • Or use the script provided, e.g.,
    PORT="/dev/ttyUSB0" BOARD="arty100T" ALG="sparkle" ARCH="rv32" make fpga-scan

  • Rebuild the Xilinx Vivado project and the bitstream for the Rocket Chip system (for developments/modifications):

    • Generate the verilog files, and then the bit-stream for the FPGA implementation, e.g.,
    BOARD="arty100T" ALG="sparkle" ARCH="rv32" make fpga-hw
    • Update a pre-built bitstream with a new bitstream, e.g.,
    BOARD="arty100T" ALG="sparkle" ARCH="rv32" make fpga-update

Acknowledgements

This work has been supported in part by EPSRC via grant EP/R012288/1 (under the RISE programme).