Cryptographic Right Answers

Yep, but depends on your use case.

E.g. "I have an API key and I want it encryptedly available to some servers, and engineers to be able to roll but not read the cred", KMS directly with a CMK is great. Otherwise: that's what the rest of the bulk encryption and key generation recommendations are for; get a DEK, use NaCl's secretbox or whatever.

DEK sharding strategies depend on your data model so that gets a little tricky to provide good advice for in this document but that's something we help clients with, sure :)

Would propose one amendment to "Random IDs": if you can rely on it being available, getentropy() is preferable to /dev/urandom.

(1) It blocks if the system has just booted and the kernel has not yet collected enough entropy to initialize the entropy pool. (Good on VMs, embedded systems, etc., where there's a risk that the initial state might be identical.) It would be nice if Linux had a file-based /dev/uxrandom that waited for the CSPRNG to be properly initialized and then behaved like /dev/urandom, but, it doesn't.

(2) Unlike getrandom(), you don't have to read the long section on "Interruption by a signal handler" or know about the special-casing for small buffers or even think about what to put in the flags argument -- getentropy() doesn't have a flags argument.

(3) Performance is a bit better than opening /dev/urandom, reading some bytes, and closing the fd, and you don't have to be careful about making sure the fd gets closed no matter the control flow. Performance is probably similar to keeping a persistent /dev/urandom fd open, except that has its own minor hygienic issues (especially in library code or multithreaded code). There are a lot fewer error-checking steps in one call to getentropy() than in opening, reading, and closing /dev/urandom.

(4) getentropy() and getrandom() are available even if /dev isn't available or whatever (like in a sandbox, etc.)

Sure. FWIW, my favorite is APIs like Python's os.urandom which just always does the right thing already (including, IIRC, in very recent versions, getentropy()/getrandom()/arc4random_buf() or whatever where available).

I feel like currently there are slightly fewer ways you could open up /dev/urandom and screw it up (you mention a few valid ones -- but now you're doing feature detection) and it's incidentally cross-platform (dev on macOS, deploy on Linux: super common) so I'm pretty comfortable with it still being the default. Maybe not in the 2020 version -- we'll see. I mean sure you can run out of fds and maybe /dev/urandom isn't (1, 9) but if those things happen you're already on your last legs :-)

Hey, can you share some crypto advice for limited embedded systems (let's say minimum being 32bit cortex-M0). Say for firmware updates, user data uploading, etc.

The longevity of Tarsnap is quite astonishing. Congrats to Colin Percival.

---

Edit: Note to self: don't promote your home made crypto around famous people. (I'm way past home made at this point, but since there is no way to tell from the outside…)

Edit2: Seriously though, why? It can't just be because I veered off topic.

---

Shameless plug: glad my own https://monocypher.org satisfies most of this, but we do have a couple departures:

Encrypting data: Monocypher provides an XChacha20 + Poly1305 AEAD construction (copied straight from the RFC 7539). Why not XSalsa20? Because XChacha20 has a little bit more security margin, and is a little bit easier to optimise.

Symmetric "signatures": Monocypher provides Blake2b, which provides a keyed mode for this. Blake2b doesn't need HMAC.

Hashing Algorithm: Blake2b again, because it's faster and immune to length extensions attacks. I'm not sure why they still recommend SHA-2. Isn't Blake2 mature enough by now?

Password Handling: Monocypher provides Argon2i. Close to the top of the list, but not quite.

Asymmetric encryption: Monocypher doesn't have a box-like construction, but it does have a key exchange function, which combined with AEAD does the same thing as NaCl's crypto_box(). This makes the library more orthogonal, and I assumed combining key exchange and AEAD wasn't error prone.

Asymmetric signatures: Monocypher defaults to EdDSA, with curve25519 and Blake2b. Why no SHA-512 instead? Because I already have Blake2b, which is faster, and I didn't want the bloat. (Ed25519 is provided as an option)

I hope those departures are boring enough.