RISC-V Post-Quantum Cryptography Extension v0.1 Enters Internal Review: vkeccak.vi Explained

Published: 2026-09-18 · Category: RISC-V Development · Reading time: ~5 min · Status: DRAFT

Timeline and status

The RISC-V Post-Quantum Cryptography (PQC) Task Group opened a two-week internal review of the PQC extension specification. Per the announcement to the tech-announce list, the review began 11 September 2026 and concludes 25 September 2026. The document is published as riscv-pqc-v0.1-20260911.pdf, and GitHub carries a matching v0.1 release tag (commit c378b65, tagged 11 Sep 2026). Source lives in github.com/riscv/riscv-pqc.

The review is chaired by Markku-Juhani O. Saarinen, who chairs both the PQC Task Group and the Cryptography SIG. Feedback goes to the tech-pqc-cryptography mailing list or as GitHub issues in the repository.

One thing to be precise about: "internal review" is not ratification. This is a v0.1 public draft — the first one — going through a comment period. Any claim that "RISC-V has standardised PQC" is wrong at this stage.

What vkeccak.vi actually does

The release note is unusually specific about the single instruction at the centre of v0.1:

Three things follow from that sentence, and they matter for implementation planning:

1. One permutation, many algorithms. Keccak-p[1600] is the shared primitive behind SHA-3, SHAKE, and the FIPS 203/204/205 schemes (ML-KEM, ML-DSA, SLH-DSA). An instruction that accelerates the permutation lifts all of them, rather than accelerating one named algorithm.
2. Round count is a parameter, not a fixed pipeline. Supporting both 24-round and 12-round means the instruction has to cover full Keccak-f[1600] as well as the reduced-round variants used by the faster, non-NIST constructions (TurboSHAKE, KangarooTwelve). That is what makes it useful for high-throughput hashing, not just compliance cryptography.
3. The .vi suffix indicates a vector form with an immediate operand — the permutation is being expressed in the vector register file, not as a scalar unit bolted on.

Note that v0.1 is described as covering the Keccak permutation. Nothing in the published text claims full ML-KEM or ML-DSA instruction coverage in this draft.

What is in the repository

The announcement points implementers at working code, which is the practical reason to look now rather than after ratification:

• Spike support patches
• QEMU support patches
• OpenSSL support patches
• Tests, in the zvknhk folder
• A hardware proof-of-concept and benchmarks hosted at karucore.com

That combination — simulator, emulator, and a real crypto library — means a team can prototype software against the draft today. The caveat is the same one that applies to every pre-ratification extension: the encoding can still change. Write the code against the draft for evaluation, not for shipping.

Why embedded teams should be watching now

Post-quantum migration is mostly discussed as a server and TLS problem, but the harder deployments are at the edge, for three reasons:

• Long field life. Industrial, automotive and utility devices ship with 10–20 year service expectations. A device commissioned in 2026 may still be in service when cryptographically relevant quantum capability is a practical concern, so "harvest now, decrypt later" is not an abstraction for those fleets.
• Asymmetric cost. PQC key exchange and signatures are substantially larger and more compute-hungry than ECC and RSA equivalents. On an MCU-class core with kilobytes of RAM, that is the difference between feasible and not.
• Retrofit is expensive. If PQC has to be added in software after the fact on a part with no Keccak acceleration, the performance and energy cost lands on the exact devices least able to absorb it.

An ISA-level Keccak permutation is the lever that changes that arithmetic. This is also the general shape of the argument for an open ISA in security work: the extension is specified in public, reviewed in public, and implemented by multiple core vendors, so a device maker is not waiting on one supplier's roadmap to get primitive acceleration.

What is not disclosed or decided

Being explicit about the gaps, because this is a review draft:

• Ratification date: none. Only the review window (11–25 September 2026) is published.
• Cycle counts, speedup factors, area cost: not published in the specification text or release note. The benchmark link (karucore.com) was not retrieved for this draft, so no performance figure is quoted here.
• Instruction encoding: not reproduced in this draft. Read the PDF before writing any assembler.
• Which profiles will eventually mandate or include it: not stated.
• Whether ML-KEM / ML-DSA get dedicated instructions beyond the shared permutation: not stated in v0.1 material.
• Silicon availability: none. No vendor has been cited as shipping this.

Engineering takeaway

If you build products with a decade-plus service life on RISC-V, the useful action this month is small: download riscv-pqc-v0.1-20260911.pdf, read the vkeccak.vi encoding, and check whether your core vendor has stated a position. You do not need to design to a v0.1 draft — but you do want to know whether the silicon you are selecting in 2026 will have a credible PQC performance story, because that question is much more expensive to revisit after hardware is locked.

Comments close 25 September 2026.

Sources

• RISC-V tech-announce list — "PQC (Keccak) Extension Internal Review Start", Markku-Juhani O. Saarinen, review period 11–25 September 2026 — https://lists.riscv.org/g/tech-announce/topics?index=88707069
• GitHub — riscv/riscv-pqc releases, tag v0.1 published 11 Sep 2026 11:29, commit c378b65 — https://github.com/riscv/riscv-pqc/releases
• Specification PDF — riscv-pqc-v0.1-20260911.pdf (linked from the release and the announcement)
• Hardware PoC and benchmarks — https://karucore.com (linked from the announcement; not retrieved for this draft)

Verification notes

• All quoted facts come from two primary sources: the RISC-V tech-announce post and the GitHub v0.1 release note. The vkeccak.vi description (Keccak-p[1600]; SHA-3, SHAKE, PQC algorithms; 24-round Keccak-f[1600] and 12-round for TurboSHAKE / KangarooTwelve) is quoted verbatim.
• The mailing-list page date on the list index shows Sep 16 for the topic listing; the announcement itself and the GitHub tag both give 11 September 2026 as the review start. The draft uses 11 September, the date stated in the announcement body.
• The interpretation that .vi denotes a vector-form instruction with an immediate is standard RISC-V naming convention applied to the instruction name, and is labelled as such. The specification PDF was not parsed to confirm the encoding — the draft explicitly says not to write assembler from it.
• No performance, area, cycle-count or speedup figure is quoted, because none appears in the announcement or release note and karucore.com was not retrieved. This is the most likely place a secondary source would invent a number.
• Internal review ≠ ratified. Stated explicitly in the body; v0.1 is the first public draft.
• No vendor has been named as shipping the extension; no availability claim is made.
• Content is deliberately framed on technical and long-lifecycle grounds. No regional or industrial-policy framing is used, per house style.