[Zvknhk] initial draft for Zvknhk (vector Keccak acceleration) #1950
Conversation
There was a problem hiding this comment.
Hey @nibrunieAtSi5, thank you so much for putting this together! I'm unfortunately swamped with other work and can't immediately devote a lot of time to the specification writing. I hope to change that in the near future.
From a high-level, I don't have a lot of feedback to provide. I guess my biggest comment is in regards to the Zvkt note which we should definitely discuss at a Crypto SiG meeting.
The other point of contention, that I'm sure we all agree, is the definition of the Zvknhk for VLEN < 256. The only idea that comes to my mind right now is to define specific instructions which output partial results of state. The other option would be to trap and emulate, and the emulation code would use a mix of scalar and vector instructions. The latter would have a large performance hit but at least its architecturally correct.
Besides technical comments, I think we should also discuss some counter-arguments to provide when we get push back due to the large EGW. I can speak from experience, which granted I don't think is representative, that most implementation won't want to implement an instruction that requires dumping a large part or the whole register file into a single FU. Maybe an implementation guide would aquiesce some concerns?
|
|
||
| As the instructions defined in this specification might be used to implement cryptographic primitives, | ||
| they must be implemented with data-independent execution latencies as defined in | ||
| link:https://github.com/riscv/riscv-isa-manual/blob/main/src/scalar-crypto.adoc#data-independent-execution-latency-subset-zkt. |
There was a problem hiding this comment.
We use Zkt as the reference for the data independent execution latency definition (this is basically a copy/paste from the vector crypto spec, I kept the same reference).
| [[zvknhk,zvknhk]] | ||
| == "Zvknhk" Extension for Vector Keccak | ||
|
|
||
| This chapter describes the `Zvknhk` Vector Cryptography extension, which adds vector instructions to compute the Keccak sponge function using in NIST SHA3 and numerous Post Quantum Cryptography (PQC) algorithms. |
There was a problem hiding this comment.
The FIPS-202 spec formally defines the Keccak construction. Can we put a reference to the publication?
| - data independent execution timing | ||
| - `vl`/`vstart` must be multiples of EGS=32 (else behavior is _reserved_) | ||
|
|
||
| All of these instructions work on 2048-bit element groups comprised of 32 64-bit elements, in element group parlance `EGS=32`, `EGW=2048` and the instructions are only defined for `SEW=64`. |
There was a problem hiding this comment.
| All of these instructions work on 2048-bit element groups comprised of 32 64-bit elements, in element group parlance `EGS=32`, `EGW=2048` and the instructions are only defined for `SEW=64`. | |
| All of these instructions work on 2048-bit element groups comprised of 32 64-bit elements. In element group parlance `EGS=32`, `EGW=2048` and the instructions are only defined for `SEW=64`. |
|
|
||
| Description:: | ||
|
|
||
| The instructions performs the number of Keccak round(s) indicated by the immediate value `imm5` plus one (1-32 round(s)) on the state contained in the `vd` vector register group. The final result is written back into the same `vd` register group. |
There was a problem hiding this comment.
| The instructions performs the number of Keccak round(s) indicated by the immediate value `imm5` plus one (1-32 round(s)) on the state contained in the `vd` vector register group. The final result is written back into the same `vd` register group. | |
| The instruction performs the number of Keccak round(s) indicated by the immediate value `imm5` plus one (1-32 round(s)) on the state contained in the `vd` vector register group. The final result is written back into the same `vd` register group. |
| The instructions performs the number of Keccak round(s) indicated by the immediate value `imm5` plus one (1-32 round(s)) on the state contained in the `vd` vector register group. The final result is written back into the same `vd` register group. | ||
|
|
||
|
|
||
| Note:: out of the 32 64-bit elements in each element groups only the lower 25 are used. The upper 7 elements follows the tail policy. |
There was a problem hiding this comment.
| Note:: out of the 32 64-bit elements in each element groups only the lower 25 are used. The upper 7 elements follows the tail policy. | |
| Note:: out of the 32 64-bit elements in each element group only the lower 25 are used. The upper 7 elements follow the tail policy. |
|
|
||
| Note:: The value of EGS makes the current state of this specification unsuitable for implementation with `VLEN < 256` (including VLEN=128 which is the current minimum mandate in RVA profiles). This is a known limitation which the PQC task group intends to address before finalizing the specification. | ||
|
|
||
| Note:: The DIEL mandate is independent from the support of `Zvkt`: Zvknhk defines instructions used primarily for cryptography and there are of little use if their execution latency can leak information about input data. |
There was a problem hiding this comment.
I'm not 100% sure if I understand this note. As I read it, my understanding is that since the Keccak instruction will never be used outside of cryptographic context, it is natural to assume that Zvkt is inferred?
If that is the intent to be conveyed, I disagree. A keccak instruction is also a very cheap and performant way of achieving a DBRG. Regardless, of the threat model. Reading this note it seems that this particular usecase is impeded. In fact, I could foresee implementations having support for Zvknhk that have non-cryptographic usage.
Creating mostly dummy shell for PQC TG proposal for Keccak instruction.
Not ready for internal nor public review yet.
cc @mjosaarinen / @lfiolhais
Changelog: