
Modern Alternatives to PGP - tptacek
https://blog.gtank.cc/modern-alternatives-to-pgp/
======
gaius_baltar
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).

~~~
tptacek
Of your list, the alternatives that George provided check off:

\- 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.

~~~
AgentME
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](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.

~~~
cperciva
_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._

Don't blame me! The encryption tool came first!

------
lucb1e
> No one was sending you encrypted emails anyway

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.

~~~
ForHackernews
> I wonder what it's caused by and how we can encourage it

Probably because many Germans have a relatively recent memory of the Stasi in
the DDR.

~~~
lucb1e
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.

~~~
Krasnol
Stasi is not that long ago.

People tend to forget what the problem was during WW2.

See rise of right wing parties (also in Germany...).

~~~
robotrout
Censorship seems to be coming from the left. I think it makes sense for
everybody to maintain as much privacy from .gov as possible.

~~~
eropple
So...you are aware that "saying that makes you an asshole" and "you _can 't_
say that" are different things, yes?

~~~
robotrout
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.

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...](https://talkingpointsmemo.com/news/tlaib-going-to-impeach-motherfucker)

~~~
Krasnol
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.

~~~
afiori
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...)

~~~
Krasnol
I don't complain about bubbles.

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.

------
jwr
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.

~~~
eropple
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.

~~~
agumonkey
Google is not necessarily forever

~~~
eropple
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.

------
tptacek
The context for this is this Go project proposal:

[https://github.com/golang/go/issues/30141](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.

~~~
drenvuk
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.

~~~
michaelmrose
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.

What should I use instead of email.

~~~
drenvuk
There is literally no good answer on the market yet.

------
kazinator
> _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.

~~~
tptacek
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_.

~~~
yardstick
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.

~~~
kazinator
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.

~~~
yardstick
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.

------
pera
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...)

~~~
NelsonMinar
Keybase is one version of a modern take on Web of Trust.
[https://keybase.io/](https://keybase.io/)

~~~
diafygi
Keybase is centralized. The GPG keyserver pool is a decentralized gossip
network of volunteer servers (I run one).

[https://sks-keyservers.net/status/](https://sks-keyservers.net/status/)

~~~
eridius
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.

~~~
diafygi
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.

------
sigil
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.

Ted Unangst of OpenBSD gave a nice talk on the design of signify:
[http://www.openbsd.org/papers/bsdcan-
signify.html](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?

------
teddyh
Everyone should be aware of two tools distributed as part of GnuPG:

1\. “gpgv”, a stand-alone minimal binary to only verify PGP signatures.
[https://gnupg.org/documentation/manuals/gnupg/gpgv.html#gpgv](https://gnupg.org/documentation/manuals/gnupg/gpgv.html#gpgv)

2\. “symcryptrun” – simple symmetric encryption tool:
[https://gnupg.org/documentation/manuals/gnupg/symcryptrun.ht...](https://gnupg.org/documentation/manuals/gnupg/symcryptrun.html#symcryptrun)

------
Jeaye
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.

------
helper
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?

[1]: [https://www.passwordstore.org/](https://www.passwordstore.org/)

~~~
Boulth
> 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.

------
kingofhdds
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!

~~~
tptacek
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.

~~~
lixtra
Magic Wormhole looks neat and I can imagine using it. But apparently it
requires:

\- 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.

~~~
kingofhdds
Also magic-wormhole relies on a hardcoded intermediary servers for which
author gives no guarantees.

~~~
tptacek
You can simply run your own. The protocol doesn't rely on the servers for
security.

~~~
kingofhdds
Running my own server for occasional file transfer is when it becomes even
smarter alternative to PGP, isn't it?

------
fanf2
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 :-(

------
bertman
> No one was sending you encrypted emails anyway,...

Ouch, the unfortunate truth.

~~~
jandrese
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.

~~~
heavenlyblue
How many people in the industry you know (besides Tech), who use an e-mail
client that is neither OS X's Mail or a web mail client?

~~~
ohithereyou
OS X's mail handles PGP just fine with the GPG Mail plugin from the GPG Suite.

~~~
X-Istence
Which is now a paid upgrade.

~~~
ohithereyou
The source is still published and you can build it from source without paying.

~~~
penagwin
I highly doubt non-techie people will want to (or be able to) find the source,
install the deps, compile and install it though.

------
g45y45
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.

~~~
justincormack
It is not recommended to use any keys for more than one purpose any more, this
can allow attacks. So this is by design.

~~~
g45y45
Right, but how does one bind the keys if they do not mutually support
encryption or signing

~~~
AgentME
PGP never uses the same key for both either. A PGP "key" is a signing key and
a decryption key bundled together and then signed by the signing key.

------
dpc_pw
What is missing is hardware keys support. :(

------
lvs
This article's basic argument is that the modern alternative to PGP (GPG) is
not to do any of the things PGP is used for. How modern!

------
jrochkind1
A side issue, but:

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

~~~
m45t3r
It is not multiplication, it is permutation (170k!).

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](https://en.m.wikipedia.org/wiki/Diceware)

~~~
m45t3r
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.

~~~
zeveb
> 170k(170k - 1)(170k - 2)

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.

------
athenot
There's also S/MIME for sending emails, which is supported by many email
clients.

Of course this assumes you are fine with the chain of trust that ends with
Certificate Authorites, but this is no different that HTTPS.

------
eikenberry
No mention of an agent. One of the nice features of GPG/PGP is gpg-agent which
lets me use GPG without having to type in a passphrase every time.

~~~
heyjudy
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.

~~~
bogomipz
Interesting, can you what are the benefits of using gpg-agent over ssh-agent
for managing ssh keys?

~~~
eikenberry
Nothing other than not needing ssh agent so it saves resources by not needing
2 agents. The gpg-agent takes care of both.

------
fishywang
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.

------
bored_12
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.

------
ggm
The modern alternative to PGP is GPG. Or, PGP.

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

------
dooglius
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.

------
mikegerwitz
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.

------
rwilson4
Short, to-the-point, and I wasn't familiar with any of these options! Love it!

~~~
davidcollantes
For the userland, there was only two tools on the post that allows signing.
How will handle file encryption?

~~~
zokier
The article does mention saltpack, discussion about it here:
[https://news.ycombinator.com/item?id=14067003](https://news.ycombinator.com/item?id=14067003)

~~~
resoluteteeth
This looks nice and it supports multiple recipients which was the first
question that popped into my head.

------
lolikoisuru
> Signatures for OS or package updates

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

------
daosyn
what about keybase? it is an attempt to basically make pgp more user-friendly
and approachable

------
jedisct1
For securely sharing data online, you may also want to consider Piknik
[https://github.com/jedisct1/piknik](https://github.com/jedisct1/piknik)

------
arisAlexis
why do we need "modern" alternatives for something that works?

------
red_admiral
minisign I can support - I use it myself.

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](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.

~~~
jedisct1
Minisign's counterpart for encryption is encpipe
([https://github.com/jedisct1/encpipe](https://github.com/jedisct1/encpipe)).

------
kenforthewin
Thanks for this. The format of original need to modern alternative is
particularly useful.

------
AnaniasAnanas
> one-time-use combinations of three English words

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.

~~~
tptacek
You're wrong. Magic Wormhole is fine, and so is XSalsa. XChacha is barely even
a thing; Bernstein formalized extended-nonce Salsa20, but not Chacha20.

~~~
bjoli
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.

~~~
tptacek
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.

