@geomys.org founder / RC F'13, F2'17
Cryptogopher / Go cryptography maintainer
https://filippo.io / https://github.com/FiloSottile
https://mkcert.dev / https://age-encryption.org
https://sunlight.dev / https://filippo.io/newsletter

@filippo.abyssdomain.expert
@geomys.org founder / RC F'13, F2'17
Cryptogopher / Go cryptography maintainer
https://filippo.io / https://github.com/FiloSottile
https://mkcert.dev / https://age-encryption.org
https://sunlight.dev / https://filippo.io/newsletter
I am impressed by how well this worked. Even the comments and README were 95% good. I guess that if you have 1. a reference implementation 2. another project in the same language for style transfer 3. a specification 4. test vectors you really can vibecode crypto. I suspect (1) is optional, too.
❄️ Our Winter 1 Batch is accepting applications through Sunday, October 18. Come spend six or twelve weeks with us!
It’s an exciting time to be building -- what could you do if given the time, space, and community to work on something that you’re really interested in?
Written by Mythos 5.1 based on filippo.io/cobblestone, github.com/FiloSottile/..., the C2SP spec, and the Wycheproof test vectors. Reviewed by Astra and then by me, line by line. I had to prompt it to make the API more idiomatic, and otherwise do truly minimal manual changes.
Cobblestone-128 chunked (aka streaming) encryption in TypeScript for Node.js 22+, Bun, Deno, and all recent browsers. One-shot, transform stream, and random access decryption APIs. Uses the Web Crypto API for AES-GCM, with fallback on the noble cryptography libraries.
No, it's worse than that. FIPS 140 wants you to have internal entropy, which in software can only mean CPU jitter. You have to go out of your way to "subvert" its intention to bring in unapproved system sources.
I'm very pleased (and mildly surprised) that at this point we have good post-quantum answers for everything, despite some unnecessary specification delays. Now we "just" need to get everything rolled out, and make Merkle Tree Certificates happen. Let’s get to work. See you in 2029.
Online backups → Restic with a long random password. Changed: I love Tarsnap, and it's doing impressively well for a 2008 design, but it relies on RSA for some of its fancier properties. Restic is boring and fully symmetric.
Website or client-server application security → If in the cloud, ALB/NLB. Otherwise: rustls, Go’s crypto/tls, BoringSSL, AWS-LC, or s2n-tls with a popular ACME client. Make sure it prioritizes X25519MLKEM768. Changed: I'm not recommending OpenSSL. Be ready for Merkle Tree Certificates next year.
Asymmetric signatures → ML-DSA-44 Changed: the time to deploy classical signatures has passed. Composite signatures are IMHO not worth it. Also, ML-DSA is very nice! Consider replacing signatures entirely with HMAC, a session token, or a transparency log, if appropriate.
Asymmetric encryption → HPKE with (MLKEM768-X25519, HKDF-SHA256, AES-128-GCM), or age with PQ keys. Changed: there used to be no good answer. We have post-quantum HPKE now!
Key exchange → X25519+ML-KEM-768 in a secure, standard protocol. Don’t roll your own key exchange protocol. Just pick X25519MLKEM768 in TLS, mlkem768x25519-sha256 in SSH, and/or MLKEM768-X25519 in HPKE and age. If you really need to and you know what you’re doing, TLS and HPKE have “exporters”.
Password handling → Argon2id or scrypt. But have you considered passkeys instead? Changed: I dropped bcrypt because the 72-byte truncation bites. Much more importantly, do you really need passwords? If you only need them for logins, could you use phishing-proof passkeys instead?
Random IDs → 32 random bytes, a.k.a. 256-bit random numbers. UUIDv4 and APIs like rand.Text will give you ~128-bit values instead, and that's usually fine, too. Use your operating system’s CSPRNG. A good library will wrap it for you.
Hash algorithm → SHA-2 is still fine, but use a real multihash if needed. Multihashing is when you need to hash multiple things at once. For example, multiple columns of a row, or a filename along with the file contents. It’s subtler than it sounds, so use SequenceHash with SHA-2.
Symmetric “signatures” → HMAC-SHA-256 Good old HMAC. Just be careful about canonicalization and parser alignment bugs. Remember to compare tags with dedicated constant-time functions. Don't roll your own YoloMAC.
Symmetric key length → Don’t stress it. 256-bit keys if you need to pick. Don’t make other decisions based on this. For example, don’t go changing the default cipher suite preferences of your TLS library. Remember that Grover doesn’t actually matter and 128-bit brute-force attacks don’t exist.
Encrypting data → If you’re in the cloud, KMS. Otherwise, XAES-256-GCM or XChaCha20Poly1305 with random nonces. If you’re encrypting more than a few MB, use Cobblestone-128. New: XAES-256-GCM and Cobblestone-128. The latter is necessary if you're encrypting more than a few MB, which does happen!
Publishing “Cryptographic Right Answers” for developers is a tradition by now. Colin Percival started in 2009, Thomas Ptacek followed up in 2015, and then Latacora carried on in 2018 and 2024. I put together a list updated for the renewed urgency of migrating to post-quantum algorithms.
Hiatus update, one month in: I've read four Dungeon Crawler Carl books on my Xteink, like a smoker who replaces the gesture with licorice sticks. The instinct to pull up the feed has faded; by now I forget about it. Maybe I can wean off the ebook, too. I'm less angry, not sure I'm more productive.
Registered directly on @eurosky.social, to use the @standard.site lexicon via @leaflet.pub!
✨ atproto ✨