- 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)
- 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)
- 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.
"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...).
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?
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:
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.
crypto_box is Curve25519 + XSalsa20-Poly1305.
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, so not always.
"Install something better"
That's a bit mysterious. Various Google searches don't suggest anything obvious.
 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.
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.
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.
gpg2 --import pubkey.gpg
gpg2 --verify-files a-message.asc
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?
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.
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 .
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 byte, so that limits how long my passphrase can be? There's also a fixed-size byte nonce, how do I store that in my computer? Maybe I should just combine them to get a 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.