Latacora, a security consultancy, writes on cryptography choices, PGP, encrypted email, SOC2 compliance and inter-service authentication.
HN commenters cite it often: The PGP Problem to argue against GnuPG, Cryptographic Right Answers for choosing boring crypto, and its SOC2 guide.
> So what do you use for signing and encryption today when setting up a heterogeneous system like email or git?
I don't. For Email, quoting the aforementioned post[0]...
> Encrypting Email
> Don’t.
> Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext.
> This isn’t going to get fixed. To make actually-secure email, you’d have to tunnel another protocol over email (you’d still be conceding traffic analysis attacks). At that point, why bother pretending?
> Encrypting email is asking for a calamity. Recommending email encryption to at-risk users is malpractice. Anyone who tells you it’s secure to communicate over PGP-encrypted email is putting their weird preferences ahead of your safety.
For signing commits in git, I'll quote Filippo[1]'s 'Sigining git commits considered harmful'[2] rant on Twitter.
> One of my issues with it is that it's marketed for a problem it does not solve (git metadata authentication and identity) and it's way suboptimal for the problem it solves (signed releases).
> I don't believe it works for that. You need at least a rebase (and key rotation, and…
A few comments:
"All passwords would be saved to the SQLite database hashed and salted with AES-256" - AES-256 is not a hash algorithm, its a symmetrical encryption algorithm.
If you "salt and hash" the passwords before you store them, you cannot retrieve the passwords again, you can only confirm that a user provided the same password now as they did when you stored it.
If you're encrypting the passwords using AES-256, you've got the meta problem of securing the encryption/decryption key (and if that's coming from your "master password" you need to ensure that it actually has enough bits of entropy and that it's suitably processed from a password/passphrase into something usable as a 256 bit AES key.
My gut feel from your wording/terminology there is that you're not yet ready to start a project that's intended to secure a collection of important passwords. Perhaps I'm wrong, and you're just using crypto-related terminology in a very loose fashion, but if I were you I'd do some more research and become at least knowledgable enough that you don't write about it as ambiguously at you have here.
A good way to start there might be to learn how the BitWarden handles the password encryption. It's open source, so you can see all the gory details, and it's been third party reviewed, so you can follow along with some of the reviewers complaints and the fixes the project made via their GitHub history.
Note that BitWarden have an interesting comment in their FAQ: "Bitwarden does…
This is a fork of tptacek's 2015's Cryptographic Right Answers Gist [1]. I think the original 2015 file is somewhat better than this fork. The fork is more up-to-date, but just offers too many options and is probably to confusing for a beginner. As far as I know, the latest "official" update to Cryptographic Right Answers is the Latacora blog post from 2018 [2].
Both the the 2015 version of Right Answers and the OP best practice guide mention (non-extended) ChaCha20-Poly1305, but if you look at their order of priorities, using NaCl/libsodium/monocypher is always mentioned first. That gives you XSalsa20-Poly1305 (NaCl, libsodium default) or XChaCha20-Poly1305 (monocypher, optional for libsodium). the non-extended ChaPoly20 is mentioned as lower priority than the extended versions, but higher priority than AES-GCM, which also features short nonces.
The same argument goes for ECC. The actual "Use" line in the document mentions NaCl, libsodium and monocypher, all of them use X25519 by default, although monocypher does not seem to offer an asymmetric encryption primitive. The main issue is the confusing language talking about ECC, when we know than some ECC (yes, I'm looking at you ECDSA) is not strictly better than RSA [3].
None of the answers in the OP guide seems wrong per se (I didn't review this thoroughly FWIW and I'm not an expert). But I'm still recommending this one, since it's simpler, and "simpler" is the entire point of this kind of guide. You want to avoid…
I stopped reading after this: "PGP is an insecure [1] and outdated [2] ecosystem that hasn't reflected cryptographic best practices in decades [3]."
The first link [1] suggests avoiding encrypted email due to potential plaintext CC issues and instead recommends Signal or (check this) WhatsApp. However, with encrypted email, I have (or can have) full control over the keys and infrastructure, a level of security that Signal or WhatsApp can't match.
The second link [2] is Moxie's rant, which I don't entirely agree with. Yes, GPG has a learning curve. But instead of teaching people how to use it, we're handed dumbed-down products like Signal (I've been using it since its early days as a simple sms encryption app, and I can tell you, it's gone downhill), which has a brilliant solution: it forces you to remember (better to say to write down) a huge random hex monstrosity just to decrypt a database backup later. And no, you can't change it.
Despite the ongoing criticisms of GPG, no suitable alternative has been put forward and the likes of Signal, Tarsnap, and others [1] simply don't cut it. Many other projects running for years (with relatively good security track records, like kernel, debian, or cpan) have no problem with GPG. This is 5c.
[1] https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
[2] https://moxie.org/2015/02/24/gpg-and-me.html
[3] https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/
Learn how basic user registration to login workflow works. I.e. user sign-up -> password hashing -> confirmation email etc. There are also "alternative" methods such as medium-style "email a login link" style logins and also stuff like OAuth. Stick with large frameworks and libraries; Rails, Omniauth and Devise, Django comes with Auth built-in. Avoid Auth frameworks which doesn't build upon its built-in systems. Learn the difference between authorization and authentication. DO NOT ATTEMPT TO ROLL YOUR OWN AUTH FOR PRODUCTION. A lot of concepts regarding Auth are simple in theory but if you have a poor grasp of the implementation language or the authentication protocol, you are going to introduce vulnerabilities. Stick to boring battle-tested stuff. Yes that means you should avoid the latest-web-framework-of-the-week-that-doesn't-include-auth when it comes to anything you want to push into production. Keep everything behind TLS if possible (Let's Encrypt et al. are free) and if you don't understand something, don't use it. If JWTs doesn't make sense to you, avoid it and stick with traditional sessions. Your SPA works perfectly fine using traditional server-side sessions and encrypted cookies without the latest hip protocol implemented by a 3rd party API gateway. Don't trust security advice from random people over the internet without doing your own research. Here is some good reading…
> For instance, most CPUs nowadays support 256-bit AES without resorting to bitslicing.
If you have the advantage of only working with newer hardware, this is true. But it's not immediately obvious whether or not your CPU supports 256-bit AES-NI without e.g. benchmarking OpenSSL.
The point isn't "AES-256 almost never supports AES-NI" (although that used to be true). It's that naively saying "biggest rock is best rock" doesn't always hold true.
> If you have to use RSA for some reason is there any scenario where you wouldn't also want 4096-bit keys?
You're sacrificing performance for a hypothetical security gain that probably won't matter. If 2048-bit RSA gets implicated by some new attack, it's more likely that 256-bit ECC will save you than 4096-bit RSA.
> https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html is an alternate, arguably better, source of information.
When people are asking for a guide on Cryptographic Right Answers, I always point people to that page.
The questions I wanted to address are about key size. And the point I wanted to stress was, "There are usually other factors that are far more important to consider than just the size of the key."
If I see a system that uses RSA to encrypt, I care more about it not using textbook RSA or poorly-implemented PKCS#1v1.5 padding than I do about 2048-bit vs 4096-bit keys.