https://github.com/riscv/riscv-crypto/releases Particularly interesting: * Zkt - Data Independent Execution Latency aka. "constant-time" -- exactly like what I've been saying we should do for years...we're most the way there already, we just need concerted effort to keep stuff from breaking rather than the current state of mostly being "constant-time" by accident. one really important point that I want to ensure you, Luke, (and others) know, so I'll repeat it even though you probably already know it: in crypto software/hardware, "constant time" doesn't literally mean "always runs in the same amount of time no matter what", instead it means "runtime doesn't depend on data", though it does depend on branch conditions, instruction fetching/address, and load/store addresses (it does not depend on load/store data for normal memory). The RISC-V spec draft linked above states: > The Zkt extension attests that the machine has data-independent > execution time for a safe subset of instructions. This property > is commonly called "constant-time" although should not be taken > with that literal meaning. * Zbkx - Crossbar permutation instructions -- like register gather, but "constant-time" * They used real executable Sail code as their specification pseudo-code
(In reply to Jacob Lifshay from comment #0) > https://github.com/riscv/riscv-crypto/releases > one really important point that I want to ensure you, Luke, (and others) > know, so I'll repeat it even though you probably already know it: i know exactly what is involved: i worked for Internet Security Systems, i have done black-box Reverse-Engineering, analysed crytographic algorithms for implementation on massive wide bit-level SIMD systems and developed a cryptographic algorithm. the amount of time and effort involved here must in NO WAY be underestimated. it is a SERIOUS, SERIOUS amount of effort that will, if tackled *right now*, ACTIVELY undermine and compromise our ability to deliver on the other milestones that we have committed to deliver. as i said already the last time this was discussed, if there are *other people* who wish to tackle constant-time design, power analysis, or other aspects of crytographic implementation and design, they are *more* than welcome to do so. i will even help them to write the requisite NLnet Grant application. we however *CANNOT* blithely retro-fit such massive and fundamental design strategies on top of *PRE-AGREED* NLnet milestones, particularly when we are only around 15% of the way through the ones that we've already committed to doing. our agreements with NLnet have been vetted and approved by independent third party audit, and CANNOT BE CHANGED. if we decide without proper thought to tackle this additional massive and highly intrusive design task *WE WILL NOT GET PAID FOR IT* under the existing budgets. please understand: it's not about whether it's a good idea or not it's not about whether it "makes things secure" it's about GETTING PAID and about NOT taking on additional unpaid complex tasks that jeapordise our existing responsibilities. so. if you believe this to be a good idea, and feel strongly about it, then put together the NLnet Grant Proposal, and find the people with the expertise to collaborate with and help implement the ideas. you will need to give accurate time estimates on the tasks in order to ensure that the budgets are adequate. you will also need to ensure that it does not interfere with the other responsibilities and obligations to complete NLnet Milestones.