Latacora

I recently came along this post [0], which pretty much killed PGP for me. I certainly cannot follow all technical detail in the post, but I do see that cryptography has moved on and now offers e.g. forward secrecy. [0] https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

I would repeat user Aaronstotle's comment that smaller teams are likely not the right audience for these levels of compliance. When it does become a concern, I think this post [0] put out by Latacora (no affiliation) is a great starting guide, although it is bent towards SOC 2 compliance. All of the items they mention are concrete wins for the business from a compliance/security perspective. The process of implementing just a few can help you better realize if your business is going to be able to muster the time and effort needed to continually work towards these standards, or if the business value isn't there yet. [0] https://latacora.micro.blog/2020/03/12/the-soc-starting.html

I think the biggest difference between them is that BLAKE3 is still quite new. I agree with https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.htm… that most cryptographic applications should make "boring" choices, and BLAKE3 is not yet boring. But assuming everything goes smoothly over the next 2-3 years, I'll start recommending BLAKE3 over BLAKE2 in essentially all cases. If you're curious about the single-threaded performance differences between BLAKE3 and BLAKE2b, I might clarify that the red bar chart at the top of the BLAKE3 readme is actually a single-threaded measurement. Everything depends on your input size though, and we have some more detailed graphs in the paper.

Fortunately, minisign does. age doesn't replace everything PGP does, which is good, because PGP does too many things. It just replaces the use case of file encryption (which itself is arguably too general; it's perhaps best to think of age as a good fallback for encryption use cases that don't have a better domain-specific tool). See https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

GnuPG should not be used anymore. https://latacora.micro.blog/2019/07/16/the-pgp-problem.html For file encryption age is recommended. A frontend for it would be welcomed. https://github.com/FiloSottile/age

The best-known problem with PGP is its poor usability, but that's not its biggest problem. It's biggest problem is an archaic design that literally predates much of modern cryptography; most egregiously, PGP is almost never forward-secret, and almost always relies on long-term keys, which is a deadly combination. A more fundamental design issue is simply that cryptography engineers long ago abandoned the idea of a single toolset or even a single standard design that handles multiple problems. Messaging cryptography is not the same as backup cryptography, which in turn isn't the same as secure transports, or package update security. More here: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

This is a really tough question to answer, because the answer depends on what you're using JWT for. JWT crams as much functionality into the format as possible, and most of that functionality isn't needed for most use cases. This means that offering an alternative requires knowing some context about what you need out of JWT in the first place. That being said, for most purposes, you can do worse than using either mutual TLS or Macaroons [0]. As always with cryptography though, the devil is in the details, so for a more thorough discussion, check out @tptacek's "A Child's Garden of Inter-Service Authentication Schemes" [1]. It's one of my favourite treatments of the topic, and discusses the tradeoffs of a few different techniques for different use-cases. [0] https://en.wikipedia.org/wiki/Macaroons_(computer_science) [1] https://latacora.micro.blog/a-childs-garden/

I'll mention this article I was directed to by jsmeaton that really highlighted a lot of the reason why there is inertia behind such UX friendly integrations of PGP backed solutions: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html It's the best break down I've seen of PGP and it really took me out of my flawed notion of PGP, and that it is maybe not so 'pretty good' as I had thought.

Not a paper but a blog, anyone know sites like https://latacora.micro.blog/?

The OpenPGP community would do more for security if they listened to serious cryptographers and began recommending better solutions. See https://latacora.micro.blog/2019/07/16/the-pgp-problem.html for more on that. And it isn't hard to find lots and lots of cryptographers agreeing with the thesis.

I used to love PGP, but I now think encrypted email is a bad idea. https://latacora.micro.blog/2020/02/19/stop-using-encrypted.html Better to use a protocol designed with encryption in mind, like Signal, to get forward secrecy, avoid leaking metadata, and have encryption always on by default. UPDATE: I have been reminded that PGP does not have to be used with email. I meant to say that I used to love using PGP with email, since that is the primary way I have used it. I will not comment on the use of PGP outside of email, since I haven't carefully examined its use in other contexts.

See https://latacora.micro.blog/2019/07/16/the-pgp-problem.html. I don't recommend it.

IMO, encrypted e-mail is a dead end. Latacora has a good blog post about it that I highly recommend: https://latacora.micro.blog/2020/02/19/stop-using-encrypted.html

Looks like this is a PGP addon for existing email web interfaces. In case anyone is considering using this, they should first think about the strong recommendation to not use encrypted email https://latacora.micro.blog/2020/02/19/stop-using-encrypted.html

This article is a pretty great: https://latacora.micro.blog/2020/03/12/the-soc-starting.html

I'm a lisper and dislike XML as much as the next guy, but XML-DSig seems like a fundamental mistake and sexp-dsig would not have been a better spec. All of the problems you get from in-band signing and encryption are still there--case in point, our blog post on how not to sign a JSON object[0] would be a fine spike on a blog post about why XML-DSig is bananas. (One counterexample I can think of: you probably wouldn't do CDATA and comments the same way as XML did, which led to Kelby Ludwig's fantastic SAML auth bypass--which also gets a review in that blog post.) [0]: https://latacora.micro.blog/2019/07/24/how-not-to.html

PGP support in an email client is worse than nothing. https://latacora.micro.blog/2019/07/16/the-pgp-problem.html > 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. In 2020, someone should know better than to to add pretend encryption to email. The metadata leaks alone should lead you to conclude that this isn't worth doing. Don't use email for secure communications, period. Use a secure messaging app like Signal, instead.

These two articles might help: https://paragonie.com/blog/2019/03/definitive-2019-guide-cryptographic… https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.htm…

This post has some claims on AES that seem out of date. For instance, most CPUs nowadays support 256-bit AES without resorting to bitslicing. And most implementations have had plenty of time to address the side-channel timing attacks from djb's paper. The recommendation for 2048-bit RSA is also a headscratcher. I get why you'd want to prefer ECC, but if you have to use RSA for some reason is there any scenario where you wouldn't also want 4096-bit keys? Mozilla's TLS and SSH recommendations are pretty solid though. https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.htm… is an alternate, arguably better, source of information.

Great job! Maybe now they'll have time to adjust their ssh-keygen documentation to fix their password cracking vulnerability. (https://latacora.micro.blog/2018/08/03/the-default-openssh.html)

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-…

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'm using express, and currently "good ol' brcrypt" (your [2]) for the reasons I mentioned and because it is battle-tested, as you say. On the "battle-tested" note in particular, I am not confident in my ability to evaluate the trustworthiness and technical competence of most of the libraries out there. And while something like this[0] provides algorithm recommendations that I trust, there are no specific implementations referenced. "Good ol' bcrypt" is widely referenced enough that I feel comfortable using it, and I would also feel comfortable using node's built-in scrypt, except for the shortcomings in its api that you and I have already mentioned (aka "things that I do not want to concern my employer with once my contract is finished"). I think it's fine enough if I stick with bcrypt, and that's what I'm planning to do, but I saw this was on the front page, so I opportunistically made the comment hoping that someone with experience in this area (e.g. tptacek) might see the question and jump in :) [0] https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.htm…

> 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…

Age is trying to avoid being an infinitely-flexible swiss army knife like GPG. It's been argued that GPG's do-everything design is the root of many problems both technically and in usability: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html. Minisign is a good similarly-small tool for doing signatures + verification of signatures and nothing else. The cryptography is similar, but the use-cases are often different. The tools both follow the UNIX philosophy of trying to do one thing well. Blenders and belt sanders both operate with motors, but no one tries to combine them into one tool. >I also don’t understand the “anything to do with email” line. Sending my public key to a recipient on an out-of-band channel and then sending an encrypted email should be completely agnostic to the underlying encryption tools, no? Yes, you can do that. Age doesn't want to involve web-of-trust, keyservers, key rotation, forward secrecy, post-compromise security, message repudiation, signing, email standards, and email client integration. All of these would be necessary for a good end-to-end encrypted messaging system. Try reading about the Signal protocol to see everything it does, and then try to figure out how to stuff it all into existing email systems. It's hard enough to get any of that stuff right even without the restriction of working inside email.

LUKS1 (2004 design) uses PBKDF2 with 2 seconds worth of iterations. It's not especially susceptible to brute force. The only reasons to be concerned are (1) your password is very weak, or (2) you initialized the LUKS volume on an extremely low power or heavily oversubscribed CPU such that 2 seconds of PBKDF2 iterations is below the 2016 NIST recommendation for 10,000 iterations. (The LUKS implementation may/should have an iteration floor that would make this (2) concern invalid, but I'm unfamiliar with the codebase and unable to speak to that.) LUKS2 uses argon2. See, e.g., Cryptographic Right Answers[1]: > Password handling > Percival, 2009: scrypt or PBKDF2. > Ptacek, 2015: In order of preference, use scrypt, bcrypt, and then if nothing else is available PBKDF2. > Latacora, 2018: In order of preference, use scrypt, argon2, bcrypt, and then if nothing else is available PBKDF2. [1]: https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.htm…

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…

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.htm… 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.

If I get any of this wrong, I claim Cunningham's Law. :) From the "Cryptographic Right Answers" [https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.htm… > Latacora, 2018: In order of preference, use scrypt, argon2, bcrypt, and then if nothing else is available PBKDF2. > Avoid: SHA-3, naked SHA-2, SHA-1, MD5. SHA2 is a decent cryptographic hashing algorithm, that is true. But a cryptographic hashing algorithm isn't what you want when storing passwords, at least, not on its own. Some of the problems with just using a hash algorithm: same passwords have the same hash; hash algos are typically fast, so brute forcing can make many attempts quickly, and they can be pre-computed into rainbow tables. There are ways to fix this (salts, work factors), but generally you shouldn't "do it yourself."; functions like those named in the quote from Cryptographic Right Answers put all that together in a nice package. scrypt, I believe, even uses SHA-2 in its construction, but also solves the aforementioned problems. The "Purpose and operation" part of the Wikipedia article for PBKDF2 (also mentioned above) goes into some of this, as well (even if it is only recommended as a last resort, I think this paragraph is educational w.r.t. the problems around passwords): https://en.wikipedia.org/wiki/PBKDF2#Purpose_and_operation