The Design of Everyday Cryptography

https://lobste.rs/rss Hits: 2
Summary

Cryptographers (and Applied Cryptographers) love to define beautiful, robust, complete protocols that solve interesting problems. And if you get enough Cryptographers (or Applied Cryptographers) into the room, they are gonna define protocols that solve a lot of interesting problems.And if we’re lucky, at least some of those interesting problems will matter to the security of a system someday.Unfortunately, any cryptographic protocol that solves sufficiently many sufficiently interesting problems will be impossible for mere mortals to use safely. It will be the Norman Door of cryptographic protocols.A nice example of an easy-to-use cryptographic interface is the KEM, or Key Encapsulation Mechanism.My favorite diagram of a KEM is from FIPS 203, above. We can also express the KEM interface as code:def kem_keygen(seed: bytes, parms: ParameterSet) -> tuple[PublicKey, PrivateKey]: # Use eldritch algebra to expand the given random seed into an actual keypair. ... return (public_key, private_key) def kem_encaps(pub: PublicKey) -> tuple[SharedSecret, Ciphertext]: # Generate a random shared secret and the ciphertext that encapsulates it. # Optionally, a test-only "derandomized" version of this function might exist, # e.g., for Wycheproof test cases. ... return (ss, ct) def kem_decaps(priv: PrivateKey, ct: Ciphertext) -> SharedSecret: # Decapsulate the ciphertext to get the shared secret inside. ... return ssAs a prospective user of this interface, it’s easy enough for me to tell that I’m supposed to use kem_keygen to generate my key, and then I can use the public key with kem_encaps and the private key with kem_decaps. Inspecting the inputs to these functions, I’m faced with the following questions:What kind of seed do I need?Which parms should I use?What should I do with my SharedSecret?For a given algorithm (e.g., ML-KEM) the first two are questions with few answers. ML-KEM, for example, takes a 64-byte seed d || z and there are 3 parameter sets targeting different security...

First seen: 2026-07-27 10:25

Last seen: 2026-07-27 11:26