Fight me.<p>I mean, happy to answer any questions.<p>By the way: if you're interested in this, you might also be interested in the set of 9 (count them: 9) new cryptopals challenges we sold off to raise money for rural congressional races on Twitter:<p><a href="https://twitter.com/search?f=tweets&q=set%208%20from%3Atqbf&src=typd" rel="nofollow">https://twitter.com/search?f=tweets&q=set%208%20from%3Atqbf&...</a><p>This is Cryptopals Set 8, before this weekend available only on request and after swearing a solemn oath not to share.
Would propose one amendment to "Random IDs": if you can rely on it being available, getentropy() is preferable to /dev/urandom.<p>(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.<p>(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.<p>(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.<p>(4) getentropy() and getrandom() are available even if /dev isn't available or whatever (like in a sandbox, etc.)
The longevity of Tarsnap is quite astonishing. Congrats to Colin Percival.<p>---<p><i>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…)</i><p><i>Edit2: Seriously though, why? It can't just be because I veered off topic.</i><p>---<p>Shameless plug: glad my own <a href="https://monocypher.org" rel="nofollow">https://monocypher.org</a> satisfies most of this, but we do have a couple departures:<p><i>Encrypting data:</i> 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.<p><i>Symmetric "signatures":</i> Monocypher provides Blake2b, which provides a keyed mode for this. Blake2b doesn't need HMAC.<p><i>Hashing Algorithm:</i> 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?<p><i>Password Handling:</i> Monocypher provides Argon2i. Close to the top of the list, but not quite.<p><i>Asymmetric encryption:</i> 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.<p><i>Asymmetric signatures:</i> 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)<p>I hope those departures are boring enough.
Just for reference, here are the source URLs for the quotes from <i>Percival, 2009</i> [1] and <i>Ptacek, 2015</i> [2].
I'm not sure about the gist, but it is what I always refer to and it's last revision is May 23, 2015.<p>[1] <a href="http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html" rel="nofollow">http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...</a><p>[2] <a href="https://gist.github.com/tqbf/be58d2d39690c3b366ad" rel="nofollow">https://gist.github.com/tqbf/be58d2d39690c3b366ad</a>
Hey, thanks for putting that together, it's a very insightful read. One thing I would mention in the section "Encrypting Data":<p>KMS is great and very useful but there are limitations, for example the 4kb payload max. Another one is latency (back and forth is OK for a single decryption step, for 10.000 it might become problematic)<p>In case you have to go around these limitations they recommend a data key that you use to encrypt the data, encrypt the data key, store both encrypted blobs in your DB and throw away away the data key from the memory as quickly as possible.<p><a href="https://docs.aws.amazon.com/kms/latest/developerguide/programming-encryption.html" rel="nofollow">https://docs.aws.amazon.com/kms/latest/developerguide/progra...</a><p>Thoughts?
Curious - why is argon2 still second to scrypt on this list?<p>I'd also question the backup solution, I think Restic is a better option due to its flexibility, I can do cheap backups to B2 and fairly reputable people seem to be approving of its cryptography:<p><a href="https://blog.filippo.io/restic-cryptography/" rel="nofollow">https://blog.filippo.io/restic-cryptography/</a><p>If anyone sees a reason why Tarsnap would be better (other than Percival's brand), I'd be quite interested.
This article was worth writing, and I'm glad you wrote it. It is helpful. You might not realise it but:<p>> If you could use KMS but encrypting is just a fun weekend project and you might be able to save some money by minimizing your KMS usage, use KMS. If you’re just encrypting secrets like API tokens for your application at startup, use SSM Parameter Store, which is KMS. You don’t have to understand how KMS works.<p>Paragraphs like this come across quite condescending, and the tone might have more to do with the lack of adoption of the ideas herein than the content does.<p>Security Professionals seem to have an unfortunate habit of talking down to everybody else.
Can anyone recommend some good cryptography books/links for someone that would like get up to speed on best practices for building secure systems? Ideally the full gamut of beginner to advanced.<p>What are the classic/authoritative texts in this space?
> Encrypting Data Percival, 2009: AES-CTR with HMAC.<p>I just found that AES-CTR + HMAC is very simple and doable in in languages like Go and Javascript for large objects which can't (or shouldn't) all be put into memory at the same time. In fact, a popular google drive client uses this: <a href="https://github.com/odeke-em/drive/wiki/End-to-End-Encryption" rel="nofollow">https://github.com/odeke-em/drive/wiki/End-to-End-Encryption</a><p>(assuming standard secure key generation for both the AES-CTR stream and the HMAC - along with a unique IV)<p>However, reading this article it seems this might no longer be recommended.
Good stuff! One minor nit suggested by someone far smarter than myself is that "it is incorrect to describe the polynomial evaluation MACs like Poly1305 and GHASH as ‘cryptographic CRC’. There _are_ cryptographic CRC-like MACs, but nobody uses them because they're more of a pain than polynomial evaluation."<p>with <a href="https://crypto.stackexchange.com/questions/56448/can-keyed-crc-be-used-as-a-mac/56450#56450" rel="nofollow">https://crypto.stackexchange.com/questions/56448/can-keyed-c...</a> as a reference :)
Can you expand on the DSA/ECDSA problems? One this I greatly dislike is having "only one option" of RSA. In my opinion, it's better to have a variety of secure algorithms available and that are well studied, so if a new attack emerges we're not completely hosed.<p>Also, while I don't believe NIST is a mouthpiece for the NSA, I'm curious why they haven't proposed some alternatives to P-256, given some of the difficultly implementing it correctly. Is anyone aware if they are working on this?
>Client-server application security
>Percival, 2009: Use OpenSSL.<p>Percival actually recommended not using SSL and shipping the server public key with the client.<p>From <a href="http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html" rel="nofollow">http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...</a><p>>Client-server application security: Distribute the server's public RSA key with the client code, and do not use SSL.<p>What are your thoughts on that approach today.
Where might people see the path forward as far as adoption of some of these "right" solutions in the larger side of the enterprise?<p>In September 2017 I had an executive pay Gartner a lot of money for a report on encryption and the result was I was directed to use Blowfish. This is obviously a ridiculous example but it's nigh impossible to get libsodium past a marketing team because they want to hear the letters "AES".
> Avoid: the OpenSSL RNG<p>Is that just historical - i.e. a tiny chance somebody is still using the broken Debian version from a decade ago - or is there actually something still insecure, or at least suspicious, even in 1.1.0+?<p>I ask only because getentropy() is not widely available in the Linux world yet, and getrandom() - and direct use of the /dev files - do have some caveats of their own.
A bit tired with "Just use HMAC". HMAC makes you pull a hash dependency, which is not much if you do software, but can be a waste of silicon if all you want is a MAC. If you already spent real estate on AES, then CMAC becomes a lot more attractive...<p>This is the reasons it's at the core of SCP03, the smartcard world is very sensitive to transistor count...
> Avoid: designing your own encrypted transport, which is a genuinely hard engineering problem; using TLS but in a default configuration, like, with “curl”; using “curl”, IPSEC.<p>I'm not sure what they're saying here. Is there a problem with the way curl handles TLS?
Also, any opinion on the Million Dollar Curve? <a href="https://cryptoexperts.github.io/million-dollar-curve" rel="nofollow">https://cryptoexperts.github.io/million-dollar-curve</a>
Can someone explain to a layman why you need to avoid RSA ? Is this only for the particular use case the article talks about or you should avoid it for other things, like encrypting a hard drive?
pgsodium is a postgres extension that adds libsodium integration to postgres, it exposes many of functions for patterns mentioned in the article, including box/secretbox, hashing, password handling, asymmetric keys, diffie-hellman, etc.<p><a href="https://github.com/michelp/pgsodium" rel="nofollow">https://github.com/michelp/pgsodium</a>
<i>Missing</i><p>1. Content security policy headers for web<p>2. "strict" Samesite cookie flags for CSRF and authentication tokens<p><i>Difference of opinion</i><p>Didn't argon2 win the last password hashing competition?