This research track follows the gap between standards and developer ergonomics.
The question is simple: how do we make post-quantum primitives understandable enough for normal product teams to adopt safely?
The Question
Post-quantum cryptography is moving from standards documents into real products, but most web developers will not read the standards before they are asked to implement something “quantum safe.” The practical question is not only which primitive is secure. It is how teams should wrap those primitives so they are hard to misuse.
I am using ML-KEM as the learning anchor because it is concrete enough to build with, yet different enough from ordinary password and token workflows to force better explanations.
What I Am Building Around
The prototype direction is a credential and transport playground: generate strong secrets, derive keys safely, experiment with hybrid key exchange, and show the data flow in a way that developers can reason about. The goal is not to invent cryptography. The goal is to make the plumbing understandable.
The most important constraint is misuse resistance. Interfaces should make unsafe defaults difficult: no raw key material in logs, no confusing encoding steps, no silent downgrade paths, and no “copy this blob somewhere” flows without explaining what the blob is.
Developer Ergonomics
Security demos often fail because they stop at the algorithm. Product teams need naming, operational boundaries, rotation plans, environment handling, and a clear answer to “what do we do if this breaks at 2 AM?”
That means the research notes include boring but necessary details: how keys are generated, how artifacts are stored, where Lambda or WebAssembly fits, what belongs client-side, what belongs server-side, and what should never be persisted.
Working Position
My current position is that most everyday web apps should adopt post-quantum cryptography through well-maintained platform libraries and managed infrastructure, not custom crypto code. But engineers still need to understand enough to evaluate tradeoffs, read migration guidance, and avoid accidental theater.
So this track is half implementation, half translation: take a difficult topic, build a small working system, and explain it without pretending the hard parts disappeared.