Repository navigation
Conversation
Optimized.decryptM decodes and decompresses each row of u into PP with 32 bits, narrows it to 16 bits at yOff i (Narrow16.narrow, uzp1) and transforms it with vg_mlkem16_ntt; the secret vector is decoded with 16 bits (Codec12W), its product with u' is the 16-bit fused dot product (DotW) and the inverse transform invW, widened into PP for the subtraction from v. The small 16-bit helpers move from Kem16 to Ops16 so that Optimized can use them. Deletes what decaps's u32 decryption alone used: ReadonlyDecrypt, the inline u32 readonly transforms (Readonly.fwd, inv, nttAt, nttInvAt, nttAtWith, nttInvAtWith) and their proofs (Readonly Fwd/Inv/Contract, nttAtWith_ok, NttR fwd_run/inv_run and their checks and literals, KemReadonlyTransform), the u32 dot product's proofs (Dot Core, Loop, Setup, LoopInput, KemDot) and the u32 decode (KemDecode, decoded_ready, DecryptU, DecryptReadonlyU/Tail). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FoYWDDEDFq1DFev5X7n2aq
Member
Author
|
The benched commit Generated by Claude Code |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Decapsulation's decryption on AArch64 now runs with 16-bit coefficients, as keygen, encaps and the re-encryption already do. It uses #3046's
vg_mlkem16_ntt, and it deletes the u32 decrypt path, which nothing else used.What changes
Optimized.decryptM:uis decoded and decompressed intoPPwith 32 bits, as before.Narrow16.narrow, narrows the row to 16 bits atyOff i. Per eight coefficients it does twoldr q, oneuzp1 .8hand onestr q, in 32 iterations.vg_mlkem16_ntt.ŝis decoded with 16 bits (Codec12W) into the consumed first matrix row.DotW), the inverse transform (invW), then a widen intoPPfor the subtraction fromvand the compression ofm'.Ops16: the small 16-bit helpers (addWAt,widenAt,dec12WAt,enc12WAt,dotAt, plus the newnarrowAt) move here fromKem16, so thatOptimizedcan use them without an import cycle. No names change.ReadonlyDecrypt, and the inline u32 readonly transformsReadonly.fwd/invwith theirnttAt/nttInvAt/nttAtWith/nttInvAtWithwrappers.Ntt16/ReadonlyFwd/Inv/Contract,nttAtWith_ok,KemReadonlyTransform;NttR.fwd_run/inv_runwith their checks and literals.Dot/Core,Loop,Setup,LoopInput,KemDot).KemDecode,decoded_ready,DecryptU) and the old decrypt proofs (DecryptReadonlyU/Tail).vg_mlkem_ntt/vg_mlkem_inv_nttand the tops' table constants, which other code still uses.Proofs
Narrow16.narrow_ok(mirrorsWiden16.widen_ok):lanes_loadandvhalf_perm_h8give the low halfwords, andCoeffsInW.write16the stores.Kem.narrowW_ok, andKem.nttW_okfor the call ofvg_mlkem16_nttfrom offsets ofx28.Optimized/DecryptW.lean:DInvW, the 16-bit counterpart ofDInv;uW_step/uW_allfor the rows ofû';m_tailWfor the tail: inverse NTT, widen, decode-decompress ofv, sub, compress.fused_m_okkeeps its statement: it is re-proven byuW_all,decode_stepW,decoded_readyW,fusedW_okandm_tailW, soDecryptStartand everything above it are unchanged.Optimized/Taints.lean: thedeStarttaint checks listVG_MLKEM16_NTT_ZETAS, since decryption now callsvg_mlkem16_ntt.TopTiming'srestSymbolsalready lists it.Benchmarks
Gate (set by the coordinating session): decaps at least 1% faster on its own and at least 2% faster together with #3046; keygen and encaps no slower than 0.7%.
Run 39693821950 on N2 (
arches=aarch64,cpu_features=-,modules=mlkem768 mlkem1024), against #3046's head7040c17. It ran on this commit before its restack ontomain(fef1e5a). The restack only brought in #3025 and #3029, which do not touch AArch64 ML-KEM. Fastest of 8 copies per side; spread ≤ 0.2%.mlkem768_keygenmlkem768_encapsmlkem768_encaps_from_bytesmlkem768_decapsmlkem1024_keygenmlkem1024_encapsmlkem1024_encaps_from_bytesmlkem1024_decapsTogether with #3046's 1.3% on decaps, that is about 3.2% (768) and 3.0% (1024). The gate is met.
Checks
lake buildandEmit.lean --checkpass on the restacked commit.src/asm/aarch64/mlkem768.rsandmlkem1024.rsare regenerated, about 3,000 fewer lines net.cargo testforaarch64-unknown-linux-gnuunderqemu-aarch64 -cpu max, with Wycheproof: all ML-KEM tests pass, both by default and withVG_CPU_FEATURES=none.check_lean_imports,check_lean_modulesandcheck_lean_public_imports(with its suggested fixes applied);check_registrationsandcheck_lean_speed;check_vectorsandcheck_arch_gates;check_variantsandcheck_mcdt.cargo fmt --checkpasses.Generated by Claude Code