Mike Ounsworth

— On the schedule —

Why have the PQC standards taken so long? Bottlenecks, bickering, and building momentum

NIST published the specifications for LMS in 2020 and ML-KEM, ML-DSA, and SLH-DSA in August 2024. Two years later, we are only beginning to see commercial deployment, and in some cases not yet even fully stable specifications for using these algorithms in the places that matter: TLS, email, code signing, passkeys, etc. This talk will explore some of the reasons that the PQC standards got stuck in the mud and what we, as the cryptographic community, can do to push past messy and time-consuming consensus-building processes to get PQC deployed on time. This topic is not mine alone, but belongs to the community, so bring your questions and opinions because I hope this turns into some lively audience interaction! Second talk — How small can you (reasonably) get an ML-DSA and ML-KEM implementation? This talk will take a deep dive into the ML-DSA and ML-KEM algorithms, specifically looking at the places in the algorithm that you can make speed-vs-memory-footprint tradeoffs. We will walk through the various components of ML-DSA and ML-KEM public and private keys, their compressed-on-disk representation, their (typical) expanded in-memory representation, and where you can get away with deferring expansion until the value is actually needed. We will look at performance and memory usage benchmarks comparing the standard and low memory implementations in the Bouncy Castle Rust library. Third talk — Lessons learned on proper cryptographic hygiene in Rust The Bouncy Castle project has spent the past year developing a brand new, from the ground up, fork of the Bouncy Castle cryptographic library in Rust. Writing cryptography that feels Rust-native has had some interesting challenges that we wish to share with the community. Developing for no_std with very careful use of heap and memory allocators. The tension between Safe Rust which gives memory-safety guarantees, and Unsafe Rust which makes it possible to produce constant-time algorithms. And designing APIs to take full advantage of strong type safety and turn runtime-error checks into compile-time checks in order to fit in the the Rust paradigm "If it compiles, then it will run successfully".