
= RISC-V Scalar Cryptography - Architectural Review Cover Letter
Ben Marshall, on behalf of the Cryptography Task Group

This document summaries the RISC-V Cryptography Task Group's submission
of the Scalar Cryptography specification for architectural review.

*Notes on specificaiton version:*

The version of the specification submitted for review is `v0.9.3`, released
on June 24'th 2021.

The release may be downloaded from
https://github.com/riscv/riscv-crypto/releases/tag/v0.9.3-scalar

We acknowledge that some prelimianary feedback from the architectural
reviewers has already been recieved, specifically around changing
zero extension to sign extension for some of the instructions.
This change has _not yet_ been made in the submitted version of the spec.
We anticipate making the change later, along with any other recommendations
from the architectural review process.

*Notes on Submission Criteria:*

    Consistency with the RISC-V architecture and philosophy

The scalar cryptography extension was designed to make lightweight
acceleration of common cryptographic workloads possible within a RISC
architecture.

All instructions read at most two GPRs, and write at most one GPR.
No instructions access memory.

All instructions are designed to be easily implemented in a single clock
cycle, or otherwise be trivial to pipeline in high performance
implementations.
We note that for instructions likely to require pipelining in high frequency
designs (AES and SM4 instructions) there is substantial literature on
implementing high frequency SBoxes, which dominate their critical path.

    Documentation clarity and completeness
      Including proper distinction between normative and non-normative text

We _hope_ our specification is clear to everyone.
To our knowledge, it has been independently implemented at least twice, by
those outside the task group.
We have included an _intended audience_ section (p3, sec 1.1) in the front
matter to make clear who we considered when writing it.

Rational or hints to implementers are contained within "Note" admonitions.
Substantial discussion on rationale and motivations for the instructions
has been moved out of the main specification and into Appendix A.

    Motivation and rationale for the features, instructions, and CSRs

The special purpose instructions for SHA2 and SHA3 are motivated by their
extremely common usage in modern encryption standards. E.g TLS 1.3.

The SM3 and SM4 instructions are similarly motivated, but are much more
relevant to cores used in China, where the SM3 and SM4 are legal requirements.

The re-packaged bitmanip-for-cryptography extensions are motivated by the
fact that though AES/SHA/SM3/4 dominate, there are many other cryptographic
algorithms which are critical workloads. The `Zbk*` extensions aim to
enable fast constant time lookup tables (`Zbkx`), efficient implementation
of GHASH, an important component of AES-GCM used in TLS 1.3 (`Zbkc`)
and general operations often found in cryptographic code, which are
inefficient to implement compared to other architectures with base RISC-V
(`Zbkb`).

All cryptography depends on a secure source of entropy for secret generation,
hence the Entropy Source extension.
This has been designed to be suitable for use across the wide variety of
implementations and use cases RISC-V caters to.
There is a rationale section specifically for the entropy source in
Appendix B.

    Utility and efficiency
      (relative to existing architectural features and mechanisms)
      Is there enough value or benefit to justify the cost of implementation
      Is the cost in terms of area, timing, and complexity reasonable

The key algorithms we aimed to accelerate (AES, SHA2, SM3 and SM4) are
2x faster with half size (SHA2, SHA3), and between 5x
(RV32 AES, SM4) and 10x (RV64 AES) faster with at least a 2x saving in
`.text` size and a 95% reduction in `.data` size.
(Faster: dynamic instruction count, smaller: static code size).

The more general-purpose instructions (`Zbk*`) are harder to evaluate, but
for important algorithms like SHA3/CSHAKE (Keccak) and ChaCha20, the improvement
is at least 2x in performance and 0.5x in code size.

Hardware costs are summarised in our stand-alone PoC
https://github.com/riscv/riscv-crypto/tree/master/rtl

We found that for the specialist instruction, the cost of integration
was negligible compared to the cost of the core instruction logic.
We believe the timing/area cost is very reasonable for the achieved code size
and performance improvements.

    Proof of Concept (PoC)
      Software PoC to ensure feature completeness and appropriateness for
      intended use cases
      Hardware PoC to demonstrate reasonable implementability

We have tracked known software and hardware PoC implementations on our
Wiki status page: https://wiki.riscv.org/x/MVcF
Some of these are slightly out of date wrt. the latest specification, but
the hardware costs are still representative.

    Inappropriate references to protected IP
      (i.e. covered by patents, copyright, etc.)

All of our work is based on either Bitmanip functionality (and so carries the
same provenance guarantees as them) or published academic work with no
known IP claims. This has been reviewed by the TPMs.

