Some problems PGP (these days, this means GnuPG) solves pretty well for me:
- offline encryption;
- distributed web of trust;
- digital signature (for messages and software packages);
- batch processing;
- certification of other users without a server at all;
- ability to use a completely "offline" infrastructure;
- sending messages without revealing the actual recipient (i.e. --hidden-recipient)
- multiplatform;
- easy to integrate in another applications and scripts;
- allowing independent encryption, signature and certification keys but using them together (i.e. I receive an encrypted message that was signed with a key certified by another key. The system must correctly detect and use the certification-only key already in my keystore);
- allows copying and pasting the data (messages, keys, etc.) in an email;
- open source and well tested implementations;
- not forcing me to use it in a mobile phone;
- for god sake, not being an Electron app!
- ideally, all this in a single package.
People keep distilling an irrational hate on OpenPGP but their proposals can't handle all these use cases. Of course, they handle some small subset very well, but none covers all of them (e.g. Signal does pretty good when I need to exchange short mobile messages, but it is of no help when I need to push a few 30 MB files from my mobile phone to GDrive without giving Google all their contents).
My frustration is that a lot of the solutions provided are raw libraries rather than end-user tools. For offline encryption, how do I encrypt a file with a password (or a keyfile)? The solutions provided are a few Go libraries, saltpack (which I think is only a spec? I couldn't find an executable), and then the Keybase service. None of these work as a simple no-strings-attached end-user replacement for `gpg -c`. This article didn't give enough for me to take `gpg -c` out of my bag of tricks. (And I do want something to replace it with! It frustrates me that it defaults to a weak password hash and AES-128 without authentication.)
Maybe the article should mention scrypt (https://www.tarsnap.com/scrypt.html) as a tool for password-based offline encryption/decryption. That tool seems like it might be a good replacement for `gpg -c`. It is frustrating though because its name is almost un-googleable (most results just talk about "scrypt" as a hashing function, rather than "scrypt" the encryption tool! It really needs a better name) and I rarely see it mentioned. It doesn't even seem to have a recommend file extension for encrypted data, which bothers me possibly more than it should. Its files aren't recognizable.
Magic wormhole is extremely cool though and does replace a big subset of my GPG usage.
It is frustrating though because its name is almost un-googleable (most results just talk about "scrypt" as a hashing function, rather than "scrypt" the encryption tool! It really needs a better name) and I rarely see it mentioned.
And https://github.com/postboy/cpwd is a full password manager that uses tarsnap's scrypt. O:-) So at least we know it can be done. The scrypt utility describes itself as a demo with some rough edges, ymmv.
> That tool seems like it might be a good replacement for `gpg -c`
The tool still can't be compiled under MinGW-w64:
./libcperciva/util/getopt.h:35:2: error: unknown type name 'sigjmp_buf'; did you mean 'jmp_buf'?
That is, there's no executable that can run natively on Windows. To compare, Git compiles and runs natively.
(I've once tried to remove the dependencies in the code, step by step, but after each step something more would be visible, so I gave up. I also don't know if it would run under Cygwin.)
Of course I don't expect the compatibility from the author, I just state that I'm not aware that the Windows version even exists, and that it limits the possibilities of the use of the tool.
> My frustration is that a lot of the solutions provided are raw libraries rather than end-user tools.
I fully agree with you. There's effectively no replacement for gpg -c as far as I see.
"It is the caller's responsibility to ensure the uniqueness of nonces" "Thus large amounts of data should be chunked so that each message is small. (Each message still needs a unique nonce.) If in doubt, 16KB is a reasonable chunk size."
It's far from being anything that can be immediately and safely used even if one were willing to use Go to compile it.
Which is sad, as gpg -c is such a basic functionality, and gpg is definitely too big and potentially problematic tool for that purpose (for years defaults of gpg -c were almost insecure, and even now it's hard, or maybe impossible, to achieve the quality that some much smaller tool could, if it existed).
My own wish: a tool that fits into single binary so that it can be easily inspected, ideally the binary itself is also as small as possible and doesn't depend on unnecessary shared libraries, uses only one algorithm of everything, but according to the best knowledge we have today. If the algorithms have to be changed to the level of incompatibility, a new tool is released (e.g tool has compatible versions 1.x until the produced files can be opened with the new version, as soon as the format changes the versions go 2.x etc, but every format version is a self contained tool which can be completely easily inspected because it supports only one format and one algorithm per purpose). And it's truly multiplatform. gpg is just too big now, but I don't know what can replace it at this moment.
> The things you don't get with these alternatives are flaws, not features, like "all being in one application".
I believe what the parent likes about "all in a single package" is the practicality and simplicity that this brings to the user: you could either just install gpg and read the man, or review tens of different relatively new applications (none of them widely used, yet) for each step of your normal workflow, learning their different interfaces and quirks, and then keeping yourself updated of any new disclosed vulnerability that may affect your custom crypto tool set.
Obviously a small application that only do one thing hopefully right should be, at least in principle, easier to maintain and audit (and therefor safer) than the ol' swiss army knife of cryptographic communications, but the convenience of all-in-one is also a reality that shouldn't be overlooked.
Guess what! Since I moved to Germany (from the Netherlands), I noticed that people send a lot of encrypted mail. Not random Germans, sure, but where in the Netherlands the security and broader hacker community was hard to convince, in Germany it's quite widespread. My colleagues (security firm) and friendly security firms (when we collaborate) expect nothing less, and even customers supporting it is not rare (it was very rare (like, one customer in dozens) when I worked in NL).
It depends on your peers whether you find PGP is usable or not, it seems.
Then again, in Germany quite a few websites used OpenStreetMap before it was cool^W^W google raised their prices, and Linux is also more widespread. I wonder what it's caused by and how we can encourage it, since I think we (HN) would generally consider those things to be good, at least for fellow hackers, even if the tech has some edges too rough for the general population.
The Dutch probably do to a similar extent. We were quite involved in the war, unfortunately, and burning records to avoid involving jews/romas/homos/etc.
But yeah it's the only thing I can think of as well. I still can't pinpoint what argument it is that they are implicitly taught that we aren't.
I think they are taught the same that the rest of us are, but their country has the first hand experience that enables them to see and understand on a deeper level just how important civil liberties and privacy is.
Nazi Germany passed laws restricting the public and private lives of “non-aryans” and other groups of people that they deemed lesser. With such laws, they turned the country from a democracy to a dictatorship. The nazis proceeded to kill millions of people, most of them Jewish.
And after that, there was like the parent commenter said the Stasi in East Germany, who was subjecting millions of people to mass surveillance.
And like I said, they have the first hand experience, so it certainly is more ingrained and near to life for the people of Germany than it is to everyone else.
In Germany, it's "you can't say that", which is I think what he's talking about. Germany is probably the most extreme in the Western world in that regard - they have e.g. a court that can ban political parties if their platform is "counter to the free democratic basic order". Not to mention minor censorship, like excising swastikas and mentions of Hitler (ironically, a recent example was with a game about how Nazis are bad and you should fight them).
Attacks on free speech in USA and Europe have nothing to do with offensive language and everything to do with control. Be careful what precedents you set and what things you celebrate. Pendulums swing.
And here we go with the currently popular victim game which also brings the famous "censorship vs. moderation" trope and the "das wird man doch wohl noch sagen dürfen" classic.
Please...this is ridiculous. Nobody falls for that besides the right wingers themselves.
Nobody wants the right circle jerk in their comment section.
The same way the right doesn't want any criticism of their behavior within their own bubble portals.
both the left and the right are in a bubble. Generally speaking assume that between your in-group there are as many bad people as in your out-group.
It is hard to make example that would not further polarize this thread, but I can promise you that the same intolerance and bubbles are present on both side of the political spectrum (for sure in the US, even if I live in Germany now I don't know much about this country...)
I brought the bubble up to demonstrate that the right is moderating all kinds of not fitting content where they are able to.
The big conspiracy the right wants to paint here based about moderation of their hate speech or pure insulting language is something that is being reinforced through their political figureheads and sold as censorship. I did not see anything like that on the other side (yet).
It's a disgusting and ridiculous play, especially in regard of real censorship which is really out there today.
While this is a good movie, one should be aware that it does not reflect the reality in Eastern Germany all that well. It's not a documentary.
In preparation for the film, the director asked Christoph Hein, an Eastern German writer, to describe the typical life of a writer in Eastern Germany (which is what the film is about). At the premiere, Hein's name was included in the opening credits, but he asked to have it removed, because he couldn't see his story in the film. He described the film as being more of a dark fairy tale than a depiction of life in 80s Eastern Germany.
He describes the movie as an overly dramatic dark fairy tale and says he doesn't recognize himself in the main character.
As far as specific criticism goes, he says the way the main character has to write in secrecy and is suppressed by the Stasi is inaccurate. He says his room was bugged in the 60s but the 80s in the DDR were supposedly much more liberal than what the film shows.
I read only the automatic Google translation to English, so this might be a misreading, but he does seem to recognize that he was being a little too pedantic in expecting historical accuracy in a dramatic work.
A friend recommended it to understand why people in certain areas of the world feel more strongly about mass surveillance. For that purpose it's a good movie -- not because of its historical accuracy, but because of its plausibility. The motivations of the characters were straightforward, and the technology unremarkable. No psychos or unobtanium needed.
That's nice and all, and I don't doubt it, but in this instance, that cultural memory is (ironically) leading Germans to use inferior cryptography, and isn't serving them well.
you know what is worse than inferior cryptography? no cryptography. security is a human problem and people like me needs a well supported tool with lots of tutorial and plugins for almost every application and a manageable sets of quirks.
I agree that the illusion of security has drawbacks, but so does using too many tools that you don't properly understand.
I have PGP keys on the keyservers but don't actively look random people up and send encrypted mail on first contact (perhaps something that can be automated). I'm surprised how often the reply I receive when contacting some German (.de) open source person is PGP encrypted.
Please sign your outgoing mails if you have a key.
Of the PGP mails I get, most are just encrypted to me.
That is cryptographically not a sound idea, but it also means that I cannot encrypt back, because I don't know which key to encrypt to.
The keyservers do not validate anything. They are just a storage medium. In fact, for my personal e-mail address, a prankster has uploaded a rogue key. There is no process by which I can ask for its removal. People who just take the key from the keyserver have a 50% chance to send me data I cannot decrypt.
This is not a PGP weakness. It has been quipped that cryptography is a method to reduce a generic problem to a key exchange problem. There is some truth to that.
One starts looking at things differently as years pass. I've been working with computers for >25 years now, and I've learned that long-term thinking is important.
Remember '.bz' files that were all the rage? Yeah. Bzip1, not '.bz2'. Good luck trying to read that.
For my data, I will stick to things that have been around for a long time and that are likely to stay. Those fancy 'nacl/box' thingies? I'm willing to make a bet that they won't be around in 5 years time.
As to PGP, it is hard to understand, so people don't use it and are not interested in developing it. Which is a shame, we could all use more good end-to-end encryption.
I also find this article rather funny, as I'm happily encrypting/decrypting data with OpenPGP, using the agent to authenticate to my SSH servers, and keep my keys securely on a YubiKey. I do hope these "modern alternatives" have good answers for storing my keys on a YubiKey, because otherwise the whole thing isn't really worth the effort.
Hm. So you think that libsodium is going to dry up and disappear from the internet in "5 years' time"? Bear in mind that its first GitHub import was in 2013 and that it is used, and supported, by lil' guys like...uh...lemme look at this..."Google".
While it's drying up and disappearing, is it going to take with it things like rbnacl which both use it transitively, package it for their environments, and also have some pretty great documentation on how it works? Is it going to take with it the public definitions of Curve25519 and XSalsa20+Poly1305? Are we going to get all neuralyzed and just...lose it?
Look, I'm no security wonk. I have some interest in it, but that's it. And even I realize that libsodium as a thing you can use if you need to will probably outlive both you and I.
Also, FWIW, it took me literally one Google search to find a bzip decompressor. I did have to read a page first, though.
> Hm. So you think that libsodium is going to dry up and disappear from the internet in "5 years' time"? Bear in mind that its first GitHub import was in 2013 and that it is used, and supported, by lil' guys like...uh...lemme look at this..."Google".
I didn't write about libsodium. I wrote about tools I can actually use to access my data — while writing my own utilities to decode my stuff is fun, it is not necessarily how I choose to spend my time. And the fact that something was written by HN celebrities doesn't change much — being revered in HN circles is not necessarily indicative of real-life performance and certainly not of software longevity :-)
You wrote about NaCl and "those fancy 'nacl/box' thingies?", of which libsodium is an implementation; if it's still around, "nacl/box thingies" aren't a problem. Further, libsodium is not by "HN celebrities". This is the modern standard recommended by every single crypto/security professional I know.
Please don't externalize this junk onto other people who may be impressionable.
Yeah, and neither are any of us. The idea that we're just going to lose incredibly central open-source projects in five years--or, frankly, fifty--is bonkers and your objection is to the color of the bikeshed.
Those fancy box thingies are very well specified and fit into 100 tweets worth of public domain ANSI C with no dependencies. If you want your format to last 100 years, I’m not sure how to ensure it better than that.
Yup--unless you think future you isn't going to be able to lay hands on a C compiler, you can literally tuck a copy of it alongside all your backups forever and ever anon.
Filippo proposes to deprecate (but not remove) Blowfish, archaic curves, CAST, MD4, RIPEMD160, TEA, Twofish, XTS, and OpenPGP from the Golang x/ libraries (which are "officially supported" but not part of the standard library.
It's really heartening to see a project get serious about shedding legacy crypto.
I was under the impression that it's mostly that it's really hart to reliably support e.g. calling 'gnupg' (cmdline), gpgme (library), etc.?
ISTR there was a company that's re-implementing the OpenPGP standard from scratch in a library-oriented-fashion, but for the life of me I can't remember their name...
I don't disagree with the 'drop legacy' stance, btw, I'm just interested in what exactly the issue is.
Yes, as the article says, it's a 1990s-style ultra-configurable do-everything design which, in practice, almost always gets deployed in a lowest-common-denominator set of constructions that are themselves mired in 1990s crypto.
No modern cryptographic engineer looking at any problem PGP solves would design a system that looked like PGP.
PGP used to make some sense as a simple at-rest storage format, but in the era of Nacl and libsodium, even that use case is a poor fit.
PGP, which is something you have to explicitly install, is a badly flawed way to encrypt files; it has a poor password KDF and you should look at how it authenticates data.
No, it's not "badly flawed". Your files won't be compromised.
GnuPG could do with better defaults, but that is true for every system good enough to have aged. A more modern KDF would also be welcome but it won't impact end user security. Just to put things in perspective.
No, that's the point. For long term encrypted storage, GnuPG is one of few options and perfectly good best practice.
Telling users that it's broken without pointing to a clear alternative is counter productive as they are likely to end up much worse.
A more modern KDF would be welcome, but it is also important to communicate the benefit to an end user: You get comparable security with a shorter password. There are other things to consider when choosing an encrypted file format.
Interesting that the comment above is off-and-on turning grey.
It's pragmatic, informative, and highlights that bashing gpg for this specific use case, without naming something better...is arguably worse than saying nothing.
Why downvote it instead of just naming a better choice? What's the big secret?
I downvoted it for making the unhinged argument that a poor KDF is a feature because it encourages users to select better passwords.
I downvote lots of things. On Hacker News, we're explicitly encouraged to downvote disagreement, especially when verbalizing that disagreement will just clutter up the thread. Everyone gets downvoted. I've been downvoted all over this thread. You were just downvoted a minute ago.
The one thing we're not supposed to do is complain about downvoting. That's in the guidelines for the site.
"making the unhinged argument that a poor KDF is a feature because it encourages users to select better passwords."
Where does it say that? It says a better kdf would improve the security of shorter passwords. I don't see anything that suggests a poor kdf is a feature.
The kdf used for "gpg -c" also seems better than "openssh enc". And we've still not heard what the reasonable alternative is for symmetric/password file encryption is. So, I'm sticking with gpg for that use case.
tptacek - What would you consider a good modern way to replace encrypting large text files to multiple PGP keys? That's my main automated use case for OpenPGP in Go. If there is a simpler, more modern way, I'd like to try it... thanks.
Edit: We do this, then push the files to a S3 bucket and users can get the files and decrypt them without having to deal with remembering/forgetting static passwords.
Replying to myself... I think I could actually use nacl/box to accomplish this. I'd just have to take care and break the large files into smaller chunks and find a way for users to easily generate and manage keys. OpenPGP sort of makes key mgt easy.
PGP is still widely deployed, whether you like it or not. "I don't like it" isn't a valid argument for considering something "legacy", when it works just fine for certain cases.
I'm not sure it's just me being behind the times, but it seems that quite a few of the ideas behind PGP (specifically: asymmetric encryption) aren't really being exploited seriously. Instead there's lots of halfhearted "oh, let's just encrypt thing X with a password stored in thing Y" where Y is presumably more 'secure'. This is a bit of a tangent, but I find it interesting and depressing that industry has learned very little, if anything.
This article explicitly points out modern alternatives to PGP's clunky, 1990s implementation of asymmetric encryption.
But, tangentially, it's a bad idea to use asymmetric encryption when you don't absolutely need it. Modern symmetric AEAD ciphers, which are implicated in pretty much all serious public-key designs anyways, are safer to use that asymmetric cryptography.
Seeing a public key in a design that doesn't demand public keys is a cryptographic engineering code smell.
I'm not so sure this is a great idea, quite commonly when reverse engineering something I need a good reliable implementation of a dated cipher. MD4 is still used in NTLM, RIPEMD160 is still used in Bitcoin and other cryptocurrencies, etc.
Systems exist outside of the Go ecosystem and not all systems are new. Compatibility is important. It's great to flag these as not recommend for new designs, but it's quite another to remove them entirely and prevent people from easily implementing compatible software. Seems more like something that should be in the documentation or spit a compiler warning if that isn't deemed loud enough.
MD5 is similarly broken but I'm assuming they don't want to remove it because it's still quite popular in some use cases - what exactly is their standard for that popularity?
Shedding? Why? The point of supporting "legacy" crypto is batteries-included and for many instances where it's vital for backwards interoperability. Makes me glad I left Go because the populist noobs have definitely taken over and ruined it with their toxic, myopic, fashionablism ideas.
All of you are using pgp wrong, emails are a crap way to use it. It's not your fault, it was meant to be used that way. There's a better way to use it though.
I want a peer to peer communication not beholden to a particular provider where I can optionally host myself where I can communicate to most people in the US. It would be optimal if I could communicate with people privately but being able to communicate with them at all is the primary point.
If holding the iphone 4 correctly could cure cancer then that metaphor would be correct. I'll take the current downvotes and back it up later when I release my project.
> The "modern alternative" is to use a much more specific and much less configurable solution to your problem.
The problem is you're replacing one configurable, flexible thing, with N different specific solutions involving multiple obscure little utilities. Oops!
How can this blogger not see that this isn't better.
How about a modern alternative to git? Instead of one hydra with so many heads, why not use scp for transferring repositories (not git push), cp -r for saving snapshots of versions (not git commit), diff -urNp for calculating differences (not git diff), patch -p1 < ... for applying deltas, not git rebase ... You know: specific solutions that do one thing, instead of one big, confusing mess.
Because it is better. You don't get sound cryptosystems from configurable, flexible things; flexibility is the mortal enemy of cryptographic soundness. That's how "this blogger" "not see" that this isn't better.
This isn't some fringe belief among hipster cryptography engineers (among which I'm sure George counts himself). You can read it straight out of _Cryptography Engineering_.
Was this reasoning true 25 years ago? If so, why don't we go back to RSA over DES3, with MD5 digests? All that dizzying proliferation of new crypto is wrecking the soundness.
I don't understand your question. We don't use RSA because it's less secure than curves. We don't use 3DES because it's an insecure cipher with a 64 bit block size. We don't use MD5 because you can generate collisions for it.
The point of not using PGP is not being a system that can negotiate us down to things like 64-bit blocks or RSA.
What if PGP was updated to remove the old cipher suites and only support modern ones like Curve25519 Poly1305 ChaCha20 etc? (At least for newly created keys/sigs/encrypted files)
The aspect of PGP I like is the UI integration. At least when using GPG Tools. I can double click on an asymmetric encrypted file and GPG tools will decrypt it. Likewise my mail client can encrypt/decrypt/sign/verify emails automatically with GPGs plugin.
If there’s a straightforward equivalent for modern crypto that is easy for users to install and use, let me know because I’d be interested in using it.
Then it will stop working for the users who have keys and data in those crypto-systems. They will have to use old, unmaintained versions of the software.
Not necessarily, it could support working with legacy algorithms to decrypt & verify old content. But any new content— any encrypt or sign- would only support modern crypto and associated features (eg newly encrypted files must be armoured / integrity checked, which I believe is optional now).
Users would need to upgrade their PGP tool sets, but all their old data would still work.
The point I was trying to drive at is all these other tools/suggestions lack a good user experience and ease of integration. GPG Tools offers the best integration for PGP I’ve seen, and is actually half decent.
If there’s a modern tool with modern crypto, easy to use, easy to integrate into mail and file management UI (Explorer/Finder/etc) then I’m all ears.
still, from a dev perspective it's not always clear what tool to use for the task. That's a lot of bike shedding for something that shouldn't be a problem in the first place: email or whatever communication system we will use in 20 years needs to have encryption baked in by default. Storing and sharing data safely need to be a first class feature of all OS and browsers.
What's the term of art for bikeshedding something so long that you give up and opt for a solution that is materially worse than all the bikeshedded options? Because that's what you're doing when you debate cryptography and give up and use OpenPGP.
As far as I can tell none of these "alternatives" implement what is at least for me the most interesting feature of PGP: web of trust and key servers. It would be really nice to see a modern take on this.
> No one was sending you encrypted emails anyway
I actually use PGP for e-mailing quite often, for instance: how am I supposed to report security issues without gpg? (please don't suggest Whatsapp...)
>how am I supposed to report security issues without gpg?
I’ve never understood this obsession with using PGP to deliver security reports (even a lot of pen testing firms do it). We trust TLS to secure all sorts of remarkably sensitive data, why do we need to add an extra layer of encryption to security reports? It just seems like an unnecessary barrier to delivering the report to me, and the user experience is terrible. On top of that managing keys and ciphertexts is an unnecessary pain. Any time I see a public key that’s some org published years or even months ago, all I can think is that in the time since they generated that, they have absolutely had a number of people who had access to the private key resign.
To me, the only threat model where something like that makes sense, is if you think your critical service providers or the government is a threat actor, and in that case PGP probably isn’t going to be enough.
Wrong layer? PGP is for person to person(s) communications, TLS is for client to server. Sometimes you can use the latter as a substitution, but not always.
Keybase is a centralized service but AIUI you don't need to actually trust the centralized Keybase service because all the actual validation is performed client-side (i.e. verifying all the proofs that the people you follow have posted) and all of the changes people make to their profiles are publicly published as a chain that is then periodically embedded into the Bitcoin blockchain.
As long as you're ok with relying on the keybase service being reachable and functional, trust is still decentralized and verifiable.
Correct. Relying on keybase's service to keep the PKI running is the definition of centralized architecture, no matter if it's publicly verifiable or not.
Also, I'm not sure how easy it is to run a private keybase PKI (anyone done this before?). For GPG/SKS keyservers, you can spin up separate pools of keyservers for private PKI pretty easily.
Depends on what you think of their Blockchain/Merkle tree work, though. The attestation chain that Keybase uses is a public merkle tree, and though currently built to be centrally signed, at the root level, still has some built in decentralized redundancy at the user/client level.
Interesting gray areas between easy determinations of whether or not something is centralized/decentralized or now.
I like keybase, I even got a bunch of my family to use it. To them it is just a free messaging app.I use it for messages and git.
I still keep PGP/GnuPG keys up and working with email because it is universal and simple. The encrypted messages I have are easy to open and get on using a fresh machine/phone as long as I keep my key around. I don't depend on anyone to maintain their servers, etc. I'm still waiting for a modern replacement, but so far it hasn't happened for me.
Yeah, their website says nothing until you hit the docs.
But I've found the app quite useful.
Essentially: a keyserver facility where you attest to your keys in public identities (like my hn profile), plus a bunch of end-to-end encrypted stuff built atop of it.
No web of trust? I would say that’s exactly the point. For tons of applications, you don’t need web of trust at all. Using PGP when you don’t want the web of trust features is an utter pain in the ass.
I want to be able to encrypt/sign and have web of trust be a different issue.
I feel like this is asking past the point. Without a web of trust, how are you securely signing?
You can go with somewhat centralized trust, but that only gets you do far. Or, rather, that forces everyone to deal with that centralized source. Much like the web of trust.
> If you own a domain and have a webserver running ssl you can distribute your public key in a secure manner.
That means that I'd be trusting GUANG DONG CERTIFICATE AUTHORITY and every other CA not to issue a fraudulent certificate against my domain. I don't think that's very secure.
Use a CAA policy in your DNS to lock down the CAs that can issue for your domain, and then monitor for issued certificates with the certificate transparency logs.
In modern browsers, certificates are not trusted if they're not CT-logged, so it's impossible for a fraudulent one to exist without you knowing about it (unless it was issued before these requirements were put in place in ~April 2018, but once all of those have expired, it'll be a pretty solid system).
That still does not help against the GP's problem. The most practical – yet totally ridiculous – solution in 2019 is still: for each end user, for each browser, to delete all pre-trusted CAs, and reenable them one-by-one trust-on-first-use. In a few days to weeks, the user ends up with around six active CAs that are actually in use, instead of dozens inactive ones that are just a backdoor waiting to happen.
> Without a web of trust, how are you securely signing?
I can only think you're making a bunch of hidden assumptions about how trust works or why you would want to sign or encrypt data. Maybe you're thinking specifically about things like email, where web of trust might make more sense.
Consider, for example, if I'm doing backups and I just want to encrypt them for my eyes only. How could a web of trust even possibly make sense in that scenario?
Why would you even need public key cryptography in that scenario? PGP solves a very real problem: secure correspondence. Encrypting stuff for yourself is much more trivial.
I'm not sure I follow. If you are decrypting with a key, either you trust it or you don't. It works or doesn't.
That is, why use a public key scheme, for private encryption? It is literally made to establish identity with someone else. Not yourself.
Even if you sign things for personal use, that is just to confirm nothing was tampered with. Which, if it was encrypted with a key, is already guaranteed. Otherwise it won't decrypt. Right?
The point is anyone can encrypt to your public key, thus, anyone could create a "backup". They won't be able to decrypt it, only you, but still having a backup that you think was created by you but wasn't can be problematic.
Why would you be taking backups created by someone else, of your things? As soon as you've done that, you are already trusting that entity with your items before they did the backup. Would it matter what any metadata is?
Consider, you are still in the game I was talking about. Did they encrypt using a secret you know (your public key) or not. If not, it doesn't decrypt. If so, it does. But you still know nothing about who they are. At all. Just that whoever it was used your public key to encrypt.
Unless you are trust a signature they provide. Note, specifically not your public key, because again, either that worked to decrypt or it didn't.
So, you are ultimately back to a web of trust. There is almost certainly no getting around that.
Thread has gone off the rails perhaps because I didn't explain how backup with PGP works. It's very simple: you have a public/private key pair. You encrypt and sign your data with that keypair as both sender AND recipient.
I am confused by the ideas that you would only encrypt without signing. I had assumed that integrity, authentication, and encryption would all be a core part of any secure backup system.
You can verify backup integrity as long as you have the public key. This is useful for monitoring systems. You wouldn't want to stick your private key, unencrypted, on some monitoring system somewhere. Performing a backup requires the private key. That's the price.
Having built this system, I can say that much of what PGP does is saddle you with pointless keychain management on top of what is, conceptually, very simple. PGP authors are actively hostile to enabling people to do things like specify keys that aren't part of your keychain. That, and PGP comes with a bunch of configurable knobs and levers that only serve to sabotage any security that you might have in a more coherent system. It reminds me a lot of using the OpenSSL command-line tools, which everyone would hide behind scripts. Unfortunately, PGP is less scriptable than OpenSSL and you have to resort to wrapping PGP in higher-level language code like Python or Go just so you can extract the status output from a separate file descriptor, because GPG doesn't even have the basic courtesy of providing useful output in its output or status codes. (Look up the --status-fd option for GPG... it's necessary any time you want to do even the most basic operation with GPG.)
Then, if you have systems where you want to do automated backup, you can give them their own keypair. If they are individually compromised they can only compromise their own backups, going forwards.
> So, you are ultimately back to a web of trust. There is almost certainly no getting around that.
I don't even remotely understand this argument. If you could spell out, from start to finish, why web of trust is necessary, then maybe I could understand what you are trying to say.
Basically, what you are describing sounds somewhat nonsensical. When you encrypt and sign data to be transmitted to someone else, 4 keys are involved. You encrypt with the receivers public key so that they can decrypt using their private key. Then, you sign with your private so that they can verify it was you with your public.
For this to work, you had to have a way to securely transmit your public key to the receiver and their public key to you. That is what the web of trust facilitates.
If you are in complete control of all locations, then you don't need to do the counter signing. Just indicate what key did the encryption on the other side. When you get it, either you can successfully decrypt, or you cannot. That is, never transmit your private key.
Now, you could self sign, I suppose. Such that you transmit another key to sign against to the remote. But what does that accomplish? If your backup system is compromised, they will have both keys on the remote. The one to encrypt, and the one to sign.
The reason I mentioned private encryption before is there is no need for authentication of data you created. Specifically the key. If you are the only one that knows the pair, then just make sure to keep one side secured. If you are worried it will ever get compromised, just make a new one every time.
The system performing the backup and the system storing the backups can (and often should) be in different locations.
What (I believe) klodolph is describing is that you can self-sign an encrypted backup and give it to an untrusted third party. When you later retrieve the backup you know that it had not been tampered by the untrusted third party.
In this case you have direct access to all private keys involved, so no web of trust is needed. In this scenario you trust a key only if you have created it yourself.
You still don't need to sign in that case. Either it wasn't tampered with and still decrypts, or it was tempered with, and no longer decrypts.
Edit: to elaborate. What is your threat model? If you are handing over encrypted data, when it is given back you are safe knowing it wasn't tampered. Either that, or the encryption scheme you used is broken.
If you are handing unencrypted data to someone else to encrypt using your public key, then you could use their public key to validate that they encrypted it. But you are, by definition, trusting that they did the encryption like you wanted them to.
Now, if you hand them a key to sign with and a key to encrypt with, you also have to give them the data to encrypt. In which case... why do you trust every link in the chain between you and them that it worked? The game is already over if they have your unencrypted data is in transit between you and someone else to start with.
PGP is downright user-hostile once you're not using web of trust. So it's true, that you don't have to use web of trust. But PGP goes out of its way to make your life hell.
For example, let's say you have a key (as an ordinary file) and a signed message in hand. How do you check that this key has signed this message, using the gpg command-line tools?
The problem with PGP is that it combines web of trust and the mechanical actions of signature verification and cryptography into one tool. It forces you to use one program both to express "trust" and to do signature verification. God forbid you should ever want to sign or encrypt something without futzing about with your keychain.
This imports a key into my keychain, maybe I don't want to import this key? It also doesn't tell me if the message was signed with the key I specified, I have to do that myself, maybe by looking closely at the output? Awful, 3/10.
I think you may have misread my comment, since I never claimed it was not possible to use PGP without web of trust. I claimed that it was a pain in the ass.
PGP’s UI isn’t user friendly to begin with, in fact, it’s notoriously bad. But that’s not the point. You try to get PGP to verify a signature without importing the key into a keychain fist.
The purported benefits of web of trust are completely irrelevant, the problem is that PGP handcuffs you to the web of trust and web of trust is often unwanted. You have to reduce and simplify your trust to something that PGP understands. There is no reason on this earth that signature verification should require importing shit into a database.
The whole philosophy of “do one thing well” would be nice here. PGP never lets you do one thing, it makes you buy the whole banana.
Pgp does not handcuff you to the web of trust. Actually most people who use pgp do not use the web of trust but instead compare fingerprints or do trust on first use.
If you do not understand this your argument is moot.
It is not because you learned in class that pgp works with the web of trust that this is what actually happens in practice
Web of trust and keyservers can be an undesirable feature among that community of users that PGP was supposed to serve: people in authoritarian states. If a community of those people sign each others’ keys, it only takes one person uploading his keyring to a public keyserver, for that authoritarian state to have a convenient map of the social network of its citizens trying to subvert its surveillance and their foreign contacts.
Very true! I am completely ok with saying that GPG is not modern cryptography, but it gives me an important asset that I do not want to lose: I have a nice key with many signatures, that means that it is relatively easy for people to check whether my signatures are mine and whether they can send me an encrypted something.
As far as I know, OpenPGP's web of trust is not cryptographically broken: it is a bunch of public key signatures over other keys, and modern signing algorithms and hasing functions are supported and used. So I think that any tool that want to present itself as "GPG done better" should at least enable me to leverage the web of trust that is already in place. Otherwise, it might be a very nice tool, but for me is a very nice tool for doing something else.
For me the most interesting feature that PGP lacks is perfect forward secrecy. I use GPG for my email (Thunderbird + Enigma) but wish I had something more modern.
I've been using minisign, signify, and ed25519 on a project and they're minimal but wonderful. They're fast, they have small key and signature sizes, and I found it way easier to integrate the reference ed25519 implementation into my project than say libgpgme or OpenSSL.
The OpenBSD use case is quite limited and doesn't require PKI, so you won't find web of trust, keyservers, or anything like that. It would be awesome to have minimal solutions to those problems as well though. Anyone aware of attempts?
What about signing my git commits to prove I authored them? As far as I know, no alternative exists for GPG there. If it did, we'd need also tools like Github to support it before it's adopted.
I do see GPG being replaced in so many areas, so I'm not opposing the OP. Just saying that I use it for signing commits every day and my engineering team is required to sign all commits; Github helps us enforce this by requiring that PRs contain only signed commits.
Its interesting that pass[1] uses GPG and was created by the author of wireguard, Jason Donenfeld. I wounder if he would build it differently if he were starting today?
I feel like the one thing that keeps me from abandoning GPG completely is the general lack of smartcard support in any other system. Are there any examples of using yubikeys to store your libsodium keys?
> Are there any examples of using yubikeys to store your libsodium keys?
I doubt it. Yubikey doesn't just store private keys in flash memory, they are using tamper resistant element. And only a couple of algorithms are supported.
So author offers to replace PGP for sending files with a piece of software which requires to send/say a password to your recipient? Oh yeah, that's smart, and very modern!
It is indeed. Magic Wormhole implements a PAKE to individually encrypt and authenticate a secure channel without requiring any other root of trust. It's exceptionally easy to use and secure.
This. If you share a temporary password through another secure channel, you can probably just share a symmetric key and then you don't need PAKE anymore. In some cases though, you might want to send yourself something from one device to the other, or you are talking to someone who's not really technical on the phone.
About being online at the same time, I was under the impression that this wasn't a requirememt.
To transfer a file, both parties do need to be online at the same time. The server (which I run) does not store the file's data: it stores tiny key-exchange messages until both sides manage to make a direct connection, but then the encrypted file data is sent from sender to recipient without being stored in the middle. So it doesn't replace email or an FTP server or some other asynchronous file-transfer service.
You're absolutely right that if you already have a secure channel, you can send a full-strength symmetric key that way (e.g. send a PGP key, or one of the alternatives in gtank's post). But PAKE enables using a low-bandwidth secure channel. I can easily read a magic-wormhole code like "4-purple-sausages" to someone over the phone or to the person sitting next to me, but I'd be hard pressed to dictate an entire 256-bit secret key correctly.
Also, if you're sending an encryption key you have to make sure it's a good key, ie generate it from a reliable source of random and with a sufficient length, whereas magic wormhole's password is automatically generated for you.
Yes, that's what I'm saying: GP's point is that if you have a secure channel you might as well send the encryption key, but in order to do that you have to be careful about generating it correctly, whereas PAKE give you the possibility to exchange something far simpler.
Well, it's nice when phone is considered secure channel. It's not so for many serious applications, however. PGP invented to deal with situations when you communication channels are untrusted. See, no one says your software is bad, but when it is marketed as a better alternative to PGP it's not true, and worse, it's absolutely irresponsible thing to do.
According to parents nice talk[1] you can add a verify switch that lets you compare the signature of the actual key. So a public authenticated channel is enough.
I'm not sure we are on the same page here. Having control over a channel you use to pass your code, I can receive your secret file, I just need to be quicker than a legitimate recipient. How this '--verify' flag will help you then?
The assumption is that Alice recognizes the voice of Bob. If Eve manages to evasdrop on the call and sits in the middle or beats Bob to connect to the wormhole server then Alice will still see that the fingerprint that Bob dictates over the phone does not match the fingerprint of the key that her computer proposes to use for the file transfer. Alice will therefore abort the transmission.
With deep learning the voice may be not good enough nowadays. Still, you only need an authenticated - possibly public - channel, similar to pgp key exchange, where you can read the fingerprint over the phone.
I need a command-line tool that does public key encryption of a few KB of data with an ASCII-armored file format. For convenient auditing, it needs to be non-repudiable, and easy to find out which keys can decrypt.
As far as I could see, the closest this article gets is saltpack, but that is an unstable alpha, and it does not appear to have a command line interface.
So no, this is not a modern alternative to PGP for my use case :-(
The only encrypted mail I get is from Facebook. It drives me crazy that nobody else bothers to put a "enter your public key here" field. It seems like it should be super easy to implement, but Facebook is literally the only company that I've ever seen do it.
The use of PGP for email is somewhere on the order of a few hundred thousand users, while S/MIME is slightly more popular at perhaps a million or two. Out of billions of email addresses.
A problem I have run into with x25519 and ed25519 is that in Nacl, both use different public key 'formats'. While they are the same curve, you cannot use an x25519 for signing (ed25519 only) and you cannot use an ed25519 for encryption. PGP allows binding encryption and signing keys together in a profile. So far I have not been able to 'bind' an ed25519/x25519 key in a similar configuration.
My point is that you need to roll your own cryptosystem, whereas PGP, for all its flaws, is a working, IND-CCA2 secure cryptosystem (provided you use the correct primitives). This whole blog is justification for removing PGP from Golang stdlib. I dont agree with Valsorda deprecating this.
> It generates those passwords for you, and they're short, one-time-use combinations of three English words
If an attacker knows the tool does this, doesn't this reduce the keyspace to crack to (number of words in an English dictionary)*3? Is that enough? Am I missing something?
A very complete dictionary has around 170K words, let's generously assume the password generator is willing to use all of them, many that will be unfamiliar and cumbersomely large to an actual native English speaker. So 510K in the keyspace, around 19 bits of "key". Maybe that's enough?
It’s enough because of the underlying PAKE technique. The passwords do not directly become the key, and an unsuccessful bruteforce attempt breaks the session.
Nope, the server gets no more power than a random network attacker. The codes are single-use, enforced by PAKE, so an attacker (or the server) gets at most one chance to guess the code for any single execution of the program.
magic-wormhole uses a 256-word list, so the two-word default provides 16 bits of entropy. But the code goes into PAKE, not a symmetric encryption key, so an attacker only gets one shot to guess it (it's an interactive protocol, so they must commit to their guess in the first message, and don't discover whether they're correct or not until the second message).
It's basically spending interactivity (and single-use-ness) to buy adequate security for a short secret. Magic-wormhole is not useful for encrypting long-term data-at-rest (because the sender needs to stick around to perform the key-exchange protocol with the receiver), nor is it useful for encrypting data to multiple parties (because the code is single-use). But it's great for getting a single file to a single person, or to establish a full-strength session key for continued use later.
Sorry, not factorial either. More like 170k(170k - 1)(170k - 2).
Generally I see people using Diceware with more than 3 words too (at least 4 or 5). However if the file does not need NSA levels of security 3 words seems fine.
Right, a 52-bit key would be terrible for symmetric encryption. But that's not what Wormhole does. It uses PAKE, which is an interactive protocol that allows two parties that both know a short password to securely come up with a longer key for symmetric encryption.
It also replaces ssh-agent. I also use monkeysphere to store SSH keys in GPG. It's a far better solution than ssh keys lying around requiring management.
Maybe I'm missing something here but I'm not sure how nacl/box and nacl/secretbox can replace openpgp in the pass use case.
Yes nacl/box and nacl/secretbox can handle the encryption and decryption part of pass, but how do they handle the key management part? With pass+openpgp, I have my key-pair, while the private key was protected by a strong passphrase, everytime I use pass it asks me for the passphrase to unlock my private key, then it's done.
With nacl/box, I need to generate a random key-pair, and then how do I securely store the private key? Maybe I use the nacl/secretbox to encrypt it and store as a file in my computer? But the key part of nacl/secretbox is a fixed-size [32]byte, so that limits how long my passphrase can be? There's also a fixed-size [24]byte nonce, how do I store that in my computer? Maybe I should just combine them to get a [56]byte as the passphrase? That may or may not be long enough as I would like it to be.
The problem for me in these alternatives is how little they take into account the users. Teaching people to use GPG has been hard enough, and now, with his proposal, for everything they do, they have to learn a new tool. Want to encrypt a file? Please, find, install, configure this tool. Want to sign something? Please, find, install, configure this tool. And many of these modern tools does not seem to have a nice UI which users can use. If these are only tools to be run on a terminal, then 'non-tech' users will not use them. And what worries me is that many of this modern alternatives have not have had sufficient crypto analysis or analysis in general. GPG is not perfect; but at least it has had analysis.
The implication that a tool like MH (or PGP) "needs" a modern alternative probably deserves to be questioned. There are nits, and there are problems, but GPGMail plugins for mail mostly work as well as anything else which is an accretion.
My corporate mail is using X.509 client certificates. LDAP (which is basically X.500-- so naturally fits X.509 information model) makes it work. We all grow a long tail
of past certificates to make sure we can unpack our own p7m data.
I don't think we ever solved how untrusted people come into trust without some form of painful mediation. The dream of the Quipu X.500 global directory remains...
One problem I see is network effects. If you use some relatively obscure encryption scheme, then it is possible for an adversary to de-anonymize you by knowing that you are one of a small group of people who use that encryption scheme.
I don't need "modern alternatives" to things that aren't broken. I'm not interested in replacing my one tool with N others when I understand my threat model and understand the benefits of my existing, battle-tested tooling.
The opening paragraph is off-putting:
> Did your last Yubikey just break?
Is this supposed to imply that I'm not supposed to be inconvenienced by my security token breaking? Of course I am. I've lost and misplaced my Nitrokey on numerous occasions, leaving me completely locked out of my systems without physical access. That's a feature, and that's intended.
> Perhaps you forgot an offline backup password.
What does that have to do with PGP?
> Maybe you're just tired of living like a spy and never using smartphones.
That absolutely has nothing to do with PGP.
> Linux distributions and many other software update mechanisms use PGP signatures to prevent malicious mirrors or network attackers from altering the contents of their packages.
GnuPG's use here is hidden from the user by the package manager. Most users have no idea it's using PGP, and don't understand what it is. They work through a package manager's abstractions. If you replaced PGP with something else, the user would likely be none the wiser. Why does it matter? Also, why do I want to abandon a keyring?
For manually verifying signatures: why does the weight of the tool matter? Is `gpgv' (which is probably already installed on your system) really weighing you down that much? Tools like signify emphasize keysize and speed compared to RSA. Do you _really_ notice as a user? Is that _really_ the bottleneck for what you're doing? It might be, but I suspect for your average user, it's not.
> I wrote one as a party trick last month – it's less than 200 lines of code and that includes some silly key parsing tricks.
Are we worried about attack surface? GPG is heavily audited---you're far more likely to be pwned through one of the 100s of other poorly audited programs on your computer. And in any case, I don't care how easy it is to write---leave the crypto to the experts. An easy-to-understand implementation is great and certainly preferred where possible, but that's only part of the battle. And tools like GnuPG already have their implementations written and audited by numerous parties over the years. That doesn't mean they're bug-free, but it's not like we're starting from scratch here.
> Original need: You want to store individual pieces of data without making their contents accessible to anyone else on your system.
I'm not arguing against the use of other programs, but I see nothing wrong with GnuPG (or PGP) for this. Again, it's a widely supported tool that's probably already available on your system, and it probably came with your distribution image, so it probably can also be trusted. Directing users to install programs is a risk in its own unless it can be authenticated through the distribution's package manager---users must understand how to verify the program themselves otherwise.
Using GnuPG also gives you some other benefits for free, like support for a smartcard, even over SSH. (You should generally prefer symmetric algorithms for long-term secrets, but if you know your threat model, or have secrets that are easily changed or don't need to stay secret long term, asymmetric may be a fine choice for you if you gain the benefit of a security token.)
> Original need: You have files that you want to send to another person, but you don't want the data to be visible in transit or stored in the cloud. For this, folks often attach an encrypted ZIP file to an email.
> Modern alternative: magic-wormhole.
This works out great (or a tool like OnionShare) if it actually addresses your problem. But what if I want to encrypt files to N people who may be online at different times, and store that file somewhere? What if I _do_ actually want to communicate over email? I happen to do most of my communication with online communities via email.
PGP does suffer from many legitimate issues, like forward secrecy. Certainly use the right tool for the job. I'm not going to use PGP as an alternative to OMEMO, for example---they're fundamentally different.
Things that certain people see as weaknesses, like logistical issues surrounding the establishment and maintenance of a web of trust, aren't weaknesses to others. I have no problem with people suggesting useful tools for certain tasks. But I'm frustrated by the FUD around PGP, as if it's insufficient for any job. It does work, it is battle-tested, and it is trusted.
For encrypting small data blobs, nacl/[secret]box is fine but as the description says it's for small blobs. If you want to store a large encrypted blob on a USB key as a backup, less so.
I personally use enchive (https://github.com/skeeto/enchive) for that, it's like the encryption counterpart to minisign and in my opinion it really should be on the list.
Wireguard, libsodium, go's crypto libraries and Google's Tink have all implemented xchacha20-poly1305. I would not say that it's not a thing, but I would probably wait at least until the ietf process is over before using it.
I know it exists, and I don't think there's anything wrong with it. It's just weird to demand that everyone use it, since, as I said, it's barely a thing.
Using "one-time-use combinations of three English words" is "fine" only if your definition of "fine" includes allowing someone with a minimal budget to find out the password in less than a year. I am seriously wondering under what definition this could be considered better than OpenPGP.
XSalsa20 is indeed fine, but XChaCha20 is better in every way. The proof for XSalsa20 provided by Bernstein applies to XChaCha20 as well.
> Using "one-time-use combinations of three English words" is "fine" only if your definition of "fine" includes allowing someone with a minimal budget to find out the password in less than a year.
Magic Wormhole uses a PAKE to establish a secure channel from a low-entropy shared secret.
- offline encryption;
- distributed web of trust;
- digital signature (for messages and software packages);
- batch processing;
- certification of other users without a server at all;
- ability to use a completely "offline" infrastructure;
- sending messages without revealing the actual recipient (i.e. --hidden-recipient)
- multiplatform;
- easy to integrate in another applications and scripts;
- allowing independent encryption, signature and certification keys but using them together (i.e. I receive an encrypted message that was signed with a key certified by another key. The system must correctly detect and use the certification-only key already in my keystore);
- allows copying and pasting the data (messages, keys, etc.) in an email;
- open source and well tested implementations;
- not forcing me to use it in a mobile phone;
- for god sake, not being an Electron app!
- ideally, all this in a single package.
People keep distilling an irrational hate on OpenPGP but their proposals can't handle all these use cases. Of course, they handle some small subset very well, but none covers all of them (e.g. Signal does pretty good when I need to exchange short mobile messages, but it is of no help when I need to push a few 30 MB files from my mobile phone to GDrive without giving Google all their contents).
- offline encryption
- digital signatures
- batch processing
- no server
- offline infrastructure
- "hidden recipient" (which, ironically, is a command line flag to mitigate a flaw in PGP, and not in fact a feature of PGP)
- multiplatform
- easy to integrate
- copying and pasting ciphertext
- open source and well-tested
- not bound to phones
- not being an electron app
The things you don't get with these alternatives are flaws, not features, like "all being in one application".
You're making George's case for him. I'd recommend reading his article again, and then following the links.
Maybe the article should mention scrypt (https://www.tarsnap.com/scrypt.html) as a tool for password-based offline encryption/decryption. That tool seems like it might be a good replacement for `gpg -c`. It is frustrating though because its name is almost un-googleable (most results just talk about "scrypt" as a hashing function, rather than "scrypt" the encryption tool! It really needs a better name) and I rarely see it mentioned. It doesn't even seem to have a recommend file extension for encrypted data, which bothers me possibly more than it should. Its files aren't recognizable.
Magic wormhole is extremely cool though and does replace a big subset of my GPG usage.
Don't blame me! The encryption tool came first!
The tool still can't be compiled under MinGW-w64:
./libcperciva/util/getopt.h:35:2: error: unknown type name 'sigjmp_buf'; did you mean 'jmp_buf'?
That is, there's no executable that can run natively on Windows. To compare, Git compiles and runs natively.
(I've once tried to remove the dependencies in the code, step by step, but after each step something more would be visible, so I gave up. I also don't know if it would run under Cygwin.)
Of course I don't expect the compatibility from the author, I just state that I'm not aware that the Windows version even exists, and that it limits the possibilities of the use of the tool.
> My frustration is that a lot of the solutions provided are raw libraries rather than end-user tools.
I fully agree with you. There's effectively no replacement for gpg -c as far as I see.
https://godoc.org/golang.org/x/crypto/nacl/secretbox
"It is the caller's responsibility to ensure the uniqueness of nonces" "Thus large amounts of data should be chunked so that each message is small. (Each message still needs a unique nonce.) If in doubt, 16KB is a reasonable chunk size."
It's far from being anything that can be immediately and safely used even if one were willing to use Go to compile it.
Which is sad, as gpg -c is such a basic functionality, and gpg is definitely too big and potentially problematic tool for that purpose (for years defaults of gpg -c were almost insecure, and even now it's hard, or maybe impossible, to achieve the quality that some much smaller tool could, if it existed).
My own wish: a tool that fits into single binary so that it can be easily inspected, ideally the binary itself is also as small as possible and doesn't depend on unnecessary shared libraries, uses only one algorithm of everything, but according to the best knowledge we have today. If the algorithms have to be changed to the level of incompatibility, a new tool is released (e.g tool has compatible versions 1.x until the produced files can be opened with the new version, as soon as the format changes the versions go 2.x etc, but every format version is a self contained tool which can be completely easily inspected because it supports only one format and one algorithm per purpose). And it's truly multiplatform. gpg is just too big now, but I don't know what can replace it at this moment.
I believe what the parent likes about "all in a single package" is the practicality and simplicity that this brings to the user: you could either just install gpg and read the man, or review tens of different relatively new applications (none of them widely used, yet) for each step of your normal workflow, learning their different interfaces and quirks, and then keeping yourself updated of any new disclosed vulnerability that may affect your custom crypto tool set.
Obviously a small application that only do one thing hopefully right should be, at least in principle, easier to maintain and audit (and therefor safer) than the ol' swiss army knife of cryptographic communications, but the convenience of all-in-one is also a reality that shouldn't be overlooked.
I don't understand. --encrypt and --decrypt are command line flags too, but surely those count as features.
Guess what! Since I moved to Germany (from the Netherlands), I noticed that people send a lot of encrypted mail. Not random Germans, sure, but where in the Netherlands the security and broader hacker community was hard to convince, in Germany it's quite widespread. My colleagues (security firm) and friendly security firms (when we collaborate) expect nothing less, and even customers supporting it is not rare (it was very rare (like, one customer in dozens) when I worked in NL).
It depends on your peers whether you find PGP is usable or not, it seems.
Then again, in Germany quite a few websites used OpenStreetMap before it was cool^W^W google raised their prices, and Linux is also more widespread. I wonder what it's caused by and how we can encourage it, since I think we (HN) would generally consider those things to be good, at least for fellow hackers, even if the tech has some edges too rough for the general population.
Probably because many Germans have a relatively recent memory of the Stasi in the DDR.
But yeah it's the only thing I can think of as well. I still can't pinpoint what argument it is that they are implicitly taught that we aren't.
Nazi Germany passed laws restricting the public and private lives of “non-aryans” and other groups of people that they deemed lesser. With such laws, they turned the country from a democracy to a dictatorship. The nazis proceeded to kill millions of people, most of them Jewish.
And after that, there was like the parent commenter said the Stasi in East Germany, who was subjecting millions of people to mass surveillance.
And like I said, they have the first hand experience, so it certainly is more ingrained and near to life for the people of Germany than it is to everyone else.
People tend to forget what the problem was during WW2.
See rise of right wing parties (also in Germany...).
https://en.wikipedia.org/wiki/Streitbare_Demokratie
Are you referring to this? I don't think anybody tried to censor her for this, even though it was incredibly offensive. https://talkingpointsmemo.com/news/tlaib-going-to-impeach-mo...
Please...this is ridiculous. Nobody falls for that besides the right wingers themselves.
Nobody wants the right circle jerk in their comment section. The same way the right doesn't want any criticism of their behavior within their own bubble portals.
It is hard to make example that would not further polarize this thread, but I can promise you that the same intolerance and bubbles are present on both side of the political spectrum (for sure in the US, even if I live in Germany now I don't know much about this country...)
I brought the bubble up to demonstrate that the right is moderating all kinds of not fitting content where they are able to.
The big conspiracy the right wants to paint here based about moderation of their hate speech or pure insulting language is something that is being reinforced through their political figureheads and sold as censorship. I did not see anything like that on the other side (yet).
It's a disgusting and ridiculous play, especially in regard of real censorship which is really out there today.
In preparation for the film, the director asked Christoph Hein, an Eastern German writer, to describe the typical life of a writer in Eastern Germany (which is what the film is about). At the premiere, Hein's name was included in the opening credits, but he asked to have it removed, because he couldn't see his story in the film. He described the film as being more of a dark fairy tale than a depiction of life in 80s Eastern Germany.
Published comments, just last month. In German -- would any bilinguals care to summarize?
https://www.sueddeutsche.de/kultur/donnersmarck-hein-das-leb...
I agree that the illusion of security has drawbacks, but so does using too many tools that you don't properly understand.
Of the PGP mails I get, most are just encrypted to me. That is cryptographically not a sound idea, but it also means that I cannot encrypt back, because I don't know which key to encrypt to.
The keyservers do not validate anything. They are just a storage medium. In fact, for my personal e-mail address, a prankster has uploaded a rogue key. There is no process by which I can ask for its removal. People who just take the key from the keyserver have a 50% chance to send me data I cannot decrypt.
This is not a PGP weakness. It has been quipped that cryptography is a method to reduce a generic problem to a key exchange problem. There is some truth to that.
It's interesting that even Edward Snowden made this mistake of sending only encrypted email.
For more elaboration about this subject K-9 resources are quite good:
https://k9mail.github.io/2017/01/30/OpenPGP-Considerations-P...
This is solved using WKD. Thunderbird already supports this with enigmail enabled
For other people there is also https://autocrypt.org/
It helps that encrypting emails is one button away on Outlook.
For the record there is GpgOL plugin installed with gpg4win.
Remember '.bz' files that were all the rage? Yeah. Bzip1, not '.bz2'. Good luck trying to read that.
For my data, I will stick to things that have been around for a long time and that are likely to stay. Those fancy 'nacl/box' thingies? I'm willing to make a bet that they won't be around in 5 years time.
As to PGP, it is hard to understand, so people don't use it and are not interested in developing it. Which is a shame, we could all use more good end-to-end encryption.
I also find this article rather funny, as I'm happily encrypting/decrypting data with OpenPGP, using the agent to authenticate to my SSH servers, and keep my keys securely on a YubiKey. I do hope these "modern alternatives" have good answers for storing my keys on a YubiKey, because otherwise the whole thing isn't really worth the effort.
While it's drying up and disappearing, is it going to take with it things like rbnacl which both use it transitively, package it for their environments, and also have some pretty great documentation on how it works? Is it going to take with it the public definitions of Curve25519 and XSalsa20+Poly1305? Are we going to get all neuralyzed and just...lose it?
Look, I'm no security wonk. I have some interest in it, but that's it. And even I realize that libsodium as a thing you can use if you need to will probably outlive both you and I.
Also, FWIW, it took me literally one Google search to find a bzip decompressor. I did have to read a page first, though.
I didn't write about libsodium. I wrote about tools I can actually use to access my data — while writing my own utilities to decode my stuff is fun, it is not necessarily how I choose to spend my time. And the fact that something was written by HN celebrities doesn't change much — being revered in HN circles is not necessarily indicative of real-life performance and certainly not of software longevity :-)
You wrote about NaCl and "those fancy 'nacl/box' thingies?", of which libsodium is an implementation; if it's still around, "nacl/box thingies" aren't a problem. Further, libsodium is not by "HN celebrities". This is the modern standard recommended by every single crypto/security professional I know.
Please don't externalize this junk onto other people who may be impressionable.
Tink implements it, though it does not rely on it.
https://tweetnacl.cr.yp.to/
crypto_box is Curve25519 + XSalsa20-Poly1305.
https://github.com/golang/go/issues/30141
Filippo proposes to deprecate (but not remove) Blowfish, archaic curves, CAST, MD4, RIPEMD160, TEA, Twofish, XTS, and OpenPGP from the Golang x/ libraries (which are "officially supported" but not part of the standard library.
It's really heartening to see a project get serious about shedding legacy crypto.
I was under the impression that it's mostly that it's really hart to reliably support e.g. calling 'gnupg' (cmdline), gpgme (library), etc.?
ISTR there was a company that's re-implementing the OpenPGP standard from scratch in a library-oriented-fashion, but for the life of me I can't remember their name...
I don't disagree with the 'drop legacy' stance, btw, I'm just interested in what exactly the issue is.
No modern cryptographic engineer looking at any problem PGP solves would design a system that looked like PGP.
PGP used to make some sense as a simple at-rest storage format, but in the era of Nacl and libsodium, even that use case is a poor fit.
The article mentions magic wormhole, but sometimes you need plain old symmetric file encryption with a password.
Or it's not useful to compare what's at hand?
Not sure I'm getting the message behind the jab.
Install something better.
Gnupg is a default package for Ubuntu[1], so not always.
"Install something better"
That's a bit mysterious. Various Google searches don't suggest anything obvious.
[1] See http://releases.ubuntu.com/bionic/ubuntu-18.04.2-live-server... ctrl-f, search for gnupg
GnuPG could do with better defaults, but that is true for every system good enough to have aged. A more modern KDF would also be welcome but it won't impact end user security. Just to put things in perspective.
...if you use it correctly. It appears that many people can't do this.
Telling users that it's broken without pointing to a clear alternative is counter productive as they are likely to end up much worse.
A more modern KDF would be welcome, but it is also important to communicate the benefit to an end user: You get comparable security with a shorter password. There are other things to consider when choosing an encrypted file format.
It's pragmatic, informative, and highlights that bashing gpg for this specific use case, without naming something better...is arguably worse than saying nothing.
Why downvote it instead of just naming a better choice? What's the big secret?
I downvote lots of things. On Hacker News, we're explicitly encouraged to downvote disagreement, especially when verbalizing that disagreement will just clutter up the thread. Everyone gets downvoted. I've been downvoted all over this thread. You were just downvoted a minute ago.
The one thing we're not supposed to do is complain about downvoting. That's in the guidelines for the site.
Where does it say that? It says a better kdf would improve the security of shorter passwords. I don't see anything that suggests a poor kdf is a feature.
The kdf used for "gpg -c" also seems better than "openssh enc". And we've still not heard what the reasonable alternative is for symmetric/password file encryption is. So, I'm sticking with gpg for that use case.
Edit: We do this, then push the files to a S3 bucket and users can get the files and decrypt them without having to deal with remembering/forgetting static passwords.
I'm not sure it's just me being behind the times, but it seems that quite a few of the ideas behind PGP (specifically: asymmetric encryption) aren't really being exploited seriously. Instead there's lots of halfhearted "oh, let's just encrypt thing X with a password stored in thing Y" where Y is presumably more 'secure'. This is a bit of a tangent, but I find it interesting and depressing that industry has learned very little, if anything.
But, tangentially, it's a bad idea to use asymmetric encryption when you don't absolutely need it. Modern symmetric AEAD ciphers, which are implicated in pretty much all serious public-key designs anyways, are safer to use that asymmetric cryptography.
Seeing a public key in a design that doesn't demand public keys is a cryptographic engineering code smell.
Systems exist outside of the Go ecosystem and not all systems are new. Compatibility is important. It's great to flag these as not recommend for new designs, but it's quite another to remove them entirely and prevent people from easily implementing compatible software. Seems more like something that should be in the documentation or spit a compiler warning if that isn't deemed loud enough.
MD5 is similarly broken but I'm assuming they don't want to remove it because it's still quite popular in some use cases - what exactly is their standard for that popularity?
What should I use instead of email.
The problem is you're replacing one configurable, flexible thing, with N different specific solutions involving multiple obscure little utilities. Oops!
How can this blogger not see that this isn't better.
How about a modern alternative to git? Instead of one hydra with so many heads, why not use scp for transferring repositories (not git push), cp -r for saving snapshots of versions (not git commit), diff -urNp for calculating differences (not git diff), patch -p1 < ... for applying deltas, not git rebase ... You know: specific solutions that do one thing, instead of one big, confusing mess.
This isn't some fringe belief among hipster cryptography engineers (among which I'm sure George counts himself). You can read it straight out of _Cryptography Engineering_.
The point of not using PGP is not being a system that can negotiate us down to things like 64-bit blocks or RSA.
The aspect of PGP I like is the UI integration. At least when using GPG Tools. I can double click on an asymmetric encrypted file and GPG tools will decrypt it. Likewise my mail client can encrypt/decrypt/sign/verify emails automatically with GPGs plugin.
If there’s a straightforward equivalent for modern crypto that is easy for users to install and use, let me know because I’d be interested in using it.
Users would need to upgrade their PGP tool sets, but all their old data would still work.
The point I was trying to drive at is all these other tools/suggestions lack a good user experience and ease of integration. GPG Tools offers the best integration for PGP I’ve seen, and is actually half decent.
If there’s a modern tool with modern crypto, easy to use, easy to integrate into mail and file management UI (Explorer/Finder/etc) then I’m all ears.
> No one was sending you encrypted emails anyway
I actually use PGP for e-mailing quite often, for instance: how am I supposed to report security issues without gpg? (please don't suggest Whatsapp...)
I’ve never understood this obsession with using PGP to deliver security reports (even a lot of pen testing firms do it). We trust TLS to secure all sorts of remarkably sensitive data, why do we need to add an extra layer of encryption to security reports? It just seems like an unnecessary barrier to delivering the report to me, and the user experience is terrible. On top of that managing keys and ciphertexts is an unnecessary pain. Any time I see a public key that’s some org published years or even months ago, all I can think is that in the time since they generated that, they have absolutely had a number of people who had access to the private key resign.
To me, the only threat model where something like that makes sense, is if you think your critical service providers or the government is a threat actor, and in that case PGP probably isn’t going to be enough.
https://sks-keyservers.net/status/
As long as you're ok with relying on the keybase service being reachable and functional, trust is still decentralized and verifiable.
Also, I'm not sure how easy it is to run a private keybase PKI (anyone done this before?). For GPG/SKS keyservers, you can spin up separate pools of keyservers for private PKI pretty easily.
For the record there is a way to encode Keybase-like proofs in plain OpenPGP: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01 for some reason Keybase decided to keep this validation centralized.
Interesting gray areas between easy determinations of whether or not something is centralized/decentralized or now.
https://keybase.io/docs/server_security
I still keep PGP/GnuPG keys up and working with email because it is universal and simple. The encrypted messages I have are easy to open and get on using a fresh machine/phone as long as I keep my key around. I don't depend on anyone to maintain their servers, etc. I'm still waiting for a modern replacement, but so far it hasn't happened for me.
Essentially: a keyserver facility where you attest to your keys in public identities (like my hn profile), plus a bunch of end-to-end encrypted stuff built atop of it.
I want to be able to encrypt/sign and have web of trust be a different issue.
You can go with somewhat centralized trust, but that only gets you do far. Or, rather, that forces everyone to deal with that centralized source. Much like the web of trust.
What situations are you encountering in 2019 where you really need a distributed web of trust?
That means that I'd be trusting GUANG DONG CERTIFICATE AUTHORITY and every other CA not to issue a fraudulent certificate against my domain. I don't think that's very secure.
In modern browsers, certificates are not trusted if they're not CT-logged, so it's impossible for a fraudulent one to exist without you knowing about it (unless it was issued before these requirements were put in place in ~April 2018, but once all of those have expired, it'll be a pretty solid system).
I can only think you're making a bunch of hidden assumptions about how trust works or why you would want to sign or encrypt data. Maybe you're thinking specifically about things like email, where web of trust might make more sense.
Consider, for example, if I'm doing backups and I just want to encrypt them for my eyes only. How could a web of trust even possibly make sense in that scenario?
I mean, yes. Pgp is a bad fit for that. So is tls.
Signing is for verification of identity over potentially compromisable channels. Not securing controlled items.
That is, why use a public key scheme, for private encryption? It is literally made to establish identity with someone else. Not yourself.
Even if you sign things for personal use, that is just to confirm nothing was tampered with. Which, if it was encrypted with a key, is already guaranteed. Otherwise it won't decrypt. Right?
Consider, you are still in the game I was talking about. Did they encrypt using a secret you know (your public key) or not. If not, it doesn't decrypt. If so, it does. But you still know nothing about who they are. At all. Just that whoever it was used your public key to encrypt.
Unless you are trust a signature they provide. Note, specifically not your public key, because again, either that worked to decrypt or it didn't.
So, you are ultimately back to a web of trust. There is almost certainly no getting around that.
Thread has gone off the rails perhaps because I didn't explain how backup with PGP works. It's very simple: you have a public/private key pair. You encrypt and sign your data with that keypair as both sender AND recipient.
I am confused by the ideas that you would only encrypt without signing. I had assumed that integrity, authentication, and encryption would all be a core part of any secure backup system.
You can verify backup integrity as long as you have the public key. This is useful for monitoring systems. You wouldn't want to stick your private key, unencrypted, on some monitoring system somewhere. Performing a backup requires the private key. That's the price.
Having built this system, I can say that much of what PGP does is saddle you with pointless keychain management on top of what is, conceptually, very simple. PGP authors are actively hostile to enabling people to do things like specify keys that aren't part of your keychain. That, and PGP comes with a bunch of configurable knobs and levers that only serve to sabotage any security that you might have in a more coherent system. It reminds me a lot of using the OpenSSL command-line tools, which everyone would hide behind scripts. Unfortunately, PGP is less scriptable than OpenSSL and you have to resort to wrapping PGP in higher-level language code like Python or Go just so you can extract the status output from a separate file descriptor, because GPG doesn't even have the basic courtesy of providing useful output in its output or status codes. (Look up the --status-fd option for GPG... it's necessary any time you want to do even the most basic operation with GPG.)
Then, if you have systems where you want to do automated backup, you can give them their own keypair. If they are individually compromised they can only compromise their own backups, going forwards.
> So, you are ultimately back to a web of trust. There is almost certainly no getting around that.
I don't even remotely understand this argument. If you could spell out, from start to finish, why web of trust is necessary, then maybe I could understand what you are trying to say.
For this to work, you had to have a way to securely transmit your public key to the receiver and their public key to you. That is what the web of trust facilitates.
If you are in complete control of all locations, then you don't need to do the counter signing. Just indicate what key did the encryption on the other side. When you get it, either you can successfully decrypt, or you cannot. That is, never transmit your private key.
Now, you could self sign, I suppose. Such that you transmit another key to sign against to the remote. But what does that accomplish? If your backup system is compromised, they will have both keys on the remote. The one to encrypt, and the one to sign.
The reason I mentioned private encryption before is there is no need for authentication of data you created. Specifically the key. If you are the only one that knows the pair, then just make sure to keep one side secured. If you are worried it will ever get compromised, just make a new one every time.
What (I believe) klodolph is describing is that you can self-sign an encrypted backup and give it to an untrusted third party. When you later retrieve the backup you know that it had not been tampered by the untrusted third party.
In this case you have direct access to all private keys involved, so no web of trust is needed. In this scenario you trust a key only if you have created it yourself.
Edit: to elaborate. What is your threat model? If you are handing over encrypted data, when it is given back you are safe knowing it wasn't tampered. Either that, or the encryption scheme you used is broken.
If you are handing unencrypted data to someone else to encrypt using your public key, then you could use their public key to validate that they encrypted it. But you are, by definition, trusting that they did the encryption like you wanted them to.
Now, if you hand them a key to sign with and a key to encrypt with, you also have to give them the data to encrypt. In which case... why do you trust every link in the chain between you and them that it worked? The game is already over if they have your unencrypted data is in transit between you and someone else to start with.
For example, let's say you have a key (as an ordinary file) and a signed message in hand. How do you check that this key has signed this message, using the gpg command-line tools?
The problem with PGP is that it combines web of trust and the mechanical actions of signature verification and cryptography into one tool. It forces you to use one program both to express "trust" and to do signature verification. God forbid you should ever want to sign or encrypt something without futzing about with your keychain.
The purported benefits of web of trust are completely irrelevant, the problem is that PGP handcuffs you to the web of trust and web of trust is often unwanted. You have to reduce and simplify your trust to something that PGP understands. There is no reason on this earth that signature verification should require importing shit into a database.
The whole philosophy of “do one thing well” would be nice here. PGP never lets you do one thing, it makes you buy the whole banana.
If you do not understand this your argument is moot.
It is not because you learned in class that pgp works with the web of trust that this is what actually happens in practice
As far as I know, OpenPGP's web of trust is not cryptographically broken: it is a bunch of public key signatures over other keys, and modern signing algorithms and hasing functions are supported and used. So I think that any tool that want to present itself as "GPG done better" should at least enable me to leverage the web of trust that is already in place. Otherwise, it might be a very nice tool, but for me is a very nice tool for doing something else.
People are quick to point to "modern" alternatives like Signal but they miss the web of trust which, correctly implemented would be a killer.
Ted Unangst of OpenBSD gave a nice talk on the design of signify: http://www.openbsd.org/papers/bsdcan-signify.html
The OpenBSD use case is quite limited and doesn't require PKI, so you won't find web of trust, keyservers, or anything like that. It would be awesome to have minimal solutions to those problems as well though. Anyone aware of attempts?
1. “gpgv”, a stand-alone minimal binary to only verify PGP signatures. https://gnupg.org/documentation/manuals/gnupg/gpgv.html#gpgv
2. “symcryptrun” – simple symmetric encryption tool: https://gnupg.org/documentation/manuals/gnupg/symcryptrun.ht...
I do see GPG being replaced in so many areas, so I'm not opposing the OP. Just saying that I use it for signing commits every day and my engineering team is required to sign all commits; Github helps us enforce this by requiring that PRs contain only signed commits.
I feel like the one thing that keeps me from abandoning GPG completely is the general lack of smartcard support in any other system. Are there any examples of using yubikeys to store your libsodium keys?
[1]: https://www.passwordstore.org/
I doubt it. Yubikey doesn't just store private keys in flash memory, they are using tamper resistant element. And only a couple of algorithms are supported.
- both parties to be online at the same time
- have access to a secured channel to transfer the secret
- Transfer a new autogenerated secret for each file transfer.
PGP lets you:
- verify the key once
- re-use the key
- the key be submitted through a public channel
- the verification be done in a public (though tamper proof) channel or by web of trust
- the file be stored in transit, no need for online
But obviously, if the complaint is that pgp is too complex, then each single tool to replace some functionality doesn’t cover the whole spectrum.
About being online at the same time, I was under the impression that this wasn't a requirememt.
To transfer a file, both parties do need to be online at the same time. The server (which I run) does not store the file's data: it stores tiny key-exchange messages until both sides manage to make a direct connection, but then the encrypted file data is sent from sender to recipient without being stored in the middle. So it doesn't replace email or an FTP server or some other asynchronous file-transfer service.
You're absolutely right that if you already have a secure channel, you can send a full-strength symmetric key that way (e.g. send a PGP key, or one of the alternatives in gtank's post). But PAKE enables using a low-bandwidth secure channel. I can easily read a magic-wormhole code like "4-purple-sausages" to someone over the phone or to the person sitting next to me, but I'd be hard pressed to dictate an entire 256-bit secret key correctly.
[1] https://youtu.be/oFrTqQw0_3c
With deep learning the voice may be not good enough nowadays. Still, you only need an authenticated - possibly public - channel, similar to pgp key exchange, where you can read the fingerprint over the phone.
Feel free to argue over other advantages you believe it has.
As far as I could see, the closest this article gets is saltpack, but that is an unstable alpha, and it does not appear to have a command line interface.
So no, this is not a modern alternative to PGP for my use case :-(
Ouch, the unfortunate truth.
Also Outlook does not support e-mail encryption out of the box.
It's amazing you had to use a throwaway just to make that statement.
> It generates those passwords for you, and they're short, one-time-use combinations of three English words
If an attacker knows the tool does this, doesn't this reduce the keyspace to crack to (number of words in an English dictionary)*3? Is that enough? Am I missing something?
A very complete dictionary has around 170K words, let's generously assume the password generator is willing to use all of them, many that will be unfamiliar and cumbersomely large to an actual native English speaker. So 510K in the keyspace, around 19 bits of "key". Maybe that's enough?
PAKE isn’t really new, but it’s certainly underused for how much it changes the password game: https://blog.cryptographyengineering.com/2018/10/19/lets-tal...
Nope, the server gets no more power than a random network attacker. The codes are single-use, enforced by PAKE, so an attacker (or the server) gets at most one chance to guess the code for any single execution of the program.
It's basically spending interactivity (and single-use-ness) to buy adequate security for a short secret. Magic-wormhole is not useful for encrypting long-term data-at-rest (because the sender needs to stick around to perform the key-exchange protocol with the receiver), nor is it useful for encrypting data to multiple parties (because the code is single-use). But it's great for getting a single file to a single person, or to establish a full-strength session key for continued use later.
I don't know how big this number is, however it is pretty big.
This technic even has a name: diceware [1].
[1]: https://en.m.wikipedia.org/wiki/Diceware
Generally I see people using Diceware with more than 3 words too (at least 4 or 5). However if the file does not need NSA levels of security 3 words seems fine.
Which is 4,912,913,300,340,000 ≈ 2^52. Fifty-two bits of entropy is pretty horrible for anything that you really care about: you want at least 128.
Of course this assumes you are fine with the chain of trust that ends with Certificate Authorites, but this is no different that HTTPS.
Yes nacl/box and nacl/secretbox can handle the encryption and decryption part of pass, but how do they handle the key management part? With pass+openpgp, I have my key-pair, while the private key was protected by a strong passphrase, everytime I use pass it asks me for the passphrase to unlock my private key, then it's done.
With nacl/box, I need to generate a random key-pair, and then how do I securely store the private key? Maybe I use the nacl/secretbox to encrypt it and store as a file in my computer? But the key part of nacl/secretbox is a fixed-size [32]byte, so that limits how long my passphrase can be? There's also a fixed-size [24]byte nonce, how do I store that in my computer? Maybe I should just combine them to get a [56]byte as the passphrase? That may or may not be long enough as I would like it to be.
The implication that a tool like MH (or PGP) "needs" a modern alternative probably deserves to be questioned. There are nits, and there are problems, but GPGMail plugins for mail mostly work as well as anything else which is an accretion.
My corporate mail is using X.509 client certificates. LDAP (which is basically X.500-- so naturally fits X.509 information model) makes it work. We all grow a long tail of past certificates to make sure we can unpack our own p7m data.
I don't think we ever solved how untrusted people come into trust without some form of painful mediation. The dream of the Quipu X.500 global directory remains...
The opening paragraph is off-putting:
> Did your last Yubikey just break?
Is this supposed to imply that I'm not supposed to be inconvenienced by my security token breaking? Of course I am. I've lost and misplaced my Nitrokey on numerous occasions, leaving me completely locked out of my systems without physical access. That's a feature, and that's intended.
> Perhaps you forgot an offline backup password.
What does that have to do with PGP?
> Maybe you're just tired of living like a spy and never using smartphones.
That absolutely has nothing to do with PGP.
> Linux distributions and many other software update mechanisms use PGP signatures to prevent malicious mirrors or network attackers from altering the contents of their packages.
GnuPG's use here is hidden from the user by the package manager. Most users have no idea it's using PGP, and don't understand what it is. They work through a package manager's abstractions. If you replaced PGP with something else, the user would likely be none the wiser. Why does it matter? Also, why do I want to abandon a keyring?
For manually verifying signatures: why does the weight of the tool matter? Is `gpgv' (which is probably already installed on your system) really weighing you down that much? Tools like signify emphasize keysize and speed compared to RSA. Do you _really_ notice as a user? Is that _really_ the bottleneck for what you're doing? It might be, but I suspect for your average user, it's not.
> I wrote one as a party trick last month – it's less than 200 lines of code and that includes some silly key parsing tricks.
Are we worried about attack surface? GPG is heavily audited---you're far more likely to be pwned through one of the 100s of other poorly audited programs on your computer. And in any case, I don't care how easy it is to write---leave the crypto to the experts. An easy-to-understand implementation is great and certainly preferred where possible, but that's only part of the battle. And tools like GnuPG already have their implementations written and audited by numerous parties over the years. That doesn't mean they're bug-free, but it's not like we're starting from scratch here.
> Original need: You want to store individual pieces of data without making their contents accessible to anyone else on your system.
I'm not arguing against the use of other programs, but I see nothing wrong with GnuPG (or PGP) for this. Again, it's a widely supported tool that's probably already available on your system, and it probably came with your distribution image, so it probably can also be trusted. Directing users to install programs is a risk in its own unless it can be authenticated through the distribution's package manager---users must understand how to verify the program themselves otherwise.
Using GnuPG also gives you some other benefits for free, like support for a smartcard, even over SSH. (You should generally prefer symmetric algorithms for long-term secrets, but if you know your threat model, or have secrets that are easily changed or don't need to stay secret long term, asymmetric may be a fine choice for you if you gain the benefit of a security token.)
> Original need: You have files that you want to send to another person, but you don't want the data to be visible in transit or stored in the cloud. For this, folks often attach an encrypted ZIP file to an email.
> Modern alternative: magic-wormhole.
This works out great (or a tool like OnionShare) if it actually addresses your problem. But what if I want to encrypt files to N people who may be online at different times, and store that file somewhere? What if I _do_ actually want to communicate over email? I happen to do most of my communication with online communities via email.
PGP does suffer from many legitimate issues, like forward secrecy. Certainly use the right tool for the job. I'm not going to use PGP as an alternative to OMEMO, for example---they're fundamentally different.
Things that certain people see as weaknesses, like logistical issues surrounding the establishment and maintenance of a web of trust, aren't weaknesses to others. I have no problem with people suggesting useful tools for certain tasks. But I'm frustrated by the FUD around PGP, as if it's insufficient for any job. It does work, it is battle-tested, and it is trusted.
> lack state or any notion of a keyring
And thus being completely useless for the purpose. This is quite a fundamental misunderstanding of the use case.
For encrypting small data blobs, nacl/[secret]box is fine but as the description says it's for small blobs. If you want to store a large encrypted blob on a USB key as a backup, less so.
I personally use enchive (https://github.com/skeeto/enchive) for that, it's like the encryption counterpart to minisign and in my opinion it really should be on the list.
I really don't think that this is secure.
> nacl/box and nacl/secretbox
Both of which use XSalsa20 - which while not broken there should be no reason to use it rather than (X)Chacha20.
XSalsa20 is indeed fine, but XChaCha20 is better in every way. The proof for XSalsa20 provided by Bernstein applies to XChaCha20 as well.
Magic Wormhole uses a PAKE to establish a secure channel from a low-entropy shared secret.