
The PGP Problem - bellinom
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
======
mstump
I was an engineer at PGP from 2004-2011 and ended up running the server team
as lead engineer. I wouldn't disagree with most of the points brought up by
the author, both the code base and standard has accreted over time and it's
incredibly complex. There were only a couple of people on the team that really
understood all the facets of either the OpenPGP or SMIME/x509 standards. It's
made worse in that it was a hack on top of another system that had accreted
over time (email) and that system was never intended to be secure. We had
massive database of malformed or non-compliant emails from every email client
since the beginning of time. The sub-packets that the author mentions were
primarily used for dealing with forwarded chains of encrypted email messages
where each previous message had it's own embedded mime-encoded
encrypted/signed messages and attachments.

The problem is that no-one else has gone through the process of establishing a
community/standard that's capable of replacing it. Each system has built their
own inoperable walled garden that doesn't work with anyone else, and none of
them have a user base large enough to make encryption easy and pervasive.

My own secret hope is that Apple is forced to open iMessage as a part of an
anti-trust action and that acts as a catalyst for interoperability.

~~~
floatingatoll
Forcing iMessage to open will immediately result in MITM iMessage proxies that
users can use to store iMessages that are meant to auto-delete, so that they
can violate the wishes of the other party. These do not exist today because
Apple binds iMessage to your hardware and bans your entire device when anyone
is found to be operating such a service, either for themselves or others.

Do you want open source clients that can be altered to ignore all privacy
criteria — or do you want closed-source clients that make a good faith effort
to adhere to auto-deletion protocols?

Pick one. There is no middle ground.

~~~
nightfly
You can violate the wishes of the other party by taking a screenshot or, in
the extreme, a photo of the screen. You're only preventing the very
lazy/unmotivated from retaining messages.

~~~
floatingatoll
Correct, screenshots are a viable attack against both closed and open source
platforms. Preventing casual retention is the best you can hope for, and is a
worthy goal regardless that it does not result in the perfection of a Faraday
cage’d clean room

~~~
darawk
So, your threat model includes MITM servers, but not cameras? It seems a
little silly to worry about the MITM problem when you can simply snap a photo
already.

~~~
bigiain
They are both valid threat models, but ones which for me have different
meanings.

Screenshotting or photographing the screen of a device owned my my intended
message recipient is a reasonably small problem to me. If my recipient wants
to expose a message I've sent them, they're going to be able to do that. I
never expected any more privacy for that message than I'd have accepted based
on my trust in that person.

MITM servers are a whole other thing. Large scale surveillance of all users of
a specific server, "full take" collection and searchable databases of messages
available effectively forever to unknown current and future opponents?

Different threats. Yeah, I'm happy enough to accept the risk of cameras in the
hands of my correspondents. Way happier than I'd be with MITMable servers (or
services that can add "ghost users" as the UK seems to be proposing).

~~~
ihattendorf
I might be missing something, but how would large scale surveillance with
searchable databases be possible with e2e encryption? They could save the
messages, but they would still be encrypted.

------
lvh
I did some "OpenPGP Best Practices" work for a client recently. They don't
have a choice, because a third party requires it. The goal was to make sure it
was as safe as possible. One thing that struck me is that I have a simplified
mental model for the PGP crypto, and reality is way weirder than that. The
blog post says it's CFB, and in a sense that's right, but it's the weirdest
bizarro variant of CFB you've ever seen.

In CFB mode, for the first block, you take an IV, encrypt it, XOR it with
plaintext. Second block: you encrypt the first ciphertext block, encrypt that,
XOR with second plaintext block, and so on. It feels sorta halfway between CBC
and CTR.

Here's the process in OpenPGP, straight from the spec because I can't repeat
this without being convinced I'm having a stroke:

    
    
       1.   The feedback register (FR) is set to the IV, which is all zeros.
    
       2.   FR is encrypted to produce FRE (FR Encrypted).  This is the
            encryption of an all-zero value.
    
       3.   FRE is xored with the first BS octets of random data prefixed to
            the plaintext to produce C[1] through C[BS], the first BS octets
            of ciphertext.
    
       4.   FR is loaded with C[1] through C[BS].
    
       5.   FR is encrypted to produce FRE, the encryption of the first BS
            octets of ciphertext.
    
       6.   The left two octets of FRE get xored with the next two octets of
            data that were prefixed to the plaintext.  This produces C[BS+1]
            and C[BS+2], the next two octets of ciphertext.
    
       7.   (The resynchronization step) FR is loaded with C[3] through
            C[BS+2].
    
       8.   FRE is xored with the first BS octets of the given plaintext,
            now that we have finished encrypting the BS+2 octets of prefixed
            data.  This produces C[BS+3] through C[BS+(BS+2)], the next BS
            octets of ciphertext.
    
       9.   FR is encrypted to produce FRE.
    
       10.  FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18
            for an 8-octet block).
    
       11.  FR is encrypted to produce FRE.
    
       12.  FRE is xored with the next BS octets of plaintext, to produce
            the next BS octets of ciphertext.  These are loaded into FR, and
            the process is repeated until the plaintext is used up.
    

Yeah so CFB except your IV isn't your IV and randomly do something with two
bytes as... an... authenticator? And then everything after that is off by two?
This isn't the only case where OpenPGP isn't just old, it's old and bizarre. I
don't have a high opinion of PGP to begin with, but even my mental model is
too charitable.

(Disclaimer: I'm a Latacora partner, didn't write this blog post but did
contribute indirectly to it.)

~~~
matthewdgreen
I think this is called Plumb CFB. It was invented by Colin Plumb back in the
day. I first saw it in their FDE products which didn’t have a good IV
generation process (kind of acting like a replacement for XTS or a wide block
cipher) and no, I don’t know what it’s for.

------
Sniffnoy
So what do I use for encrypted messaging that can, like, replace email, then?
Nobody seems to have provided any sort of satisfactory answer to this
question. To be clear, an answer this has to not just be a secure way of
sending messages, it also has to replicate the _social_ affordances of email.

E.g., things distinguishing how email is used from how text-messaging is used:

1\. Email is potentially long-form. I sit down and type it from my computer.
Text-messaging is always short, although possibly it's a series of short
messages. A series of short emails, by contrast, is an annoyance; it's
something you try to avoid sending (even though you inevitably do when it
turns out you got something wrong). Similarly, you don't typically hold rapid-
fire conversations over email.

2\. On that point, email says, you don't need to read this immediately. I
expect a text message will be probably be read in a few minutes, and probably
replied to later that day (if there's no particular urgency). I expect an
email will be probably read in a few hours, and probably replied to in a few
days (if there's no particular urgency).

3\. It's OK to cold-email people. To text someone you need their phone number;
it's for people you know. By contrast, email addresses are things that people
frequently make public specifically so that strangers can contact them.

So what am I supposed to do for secure messaging that replicates that? The
best answer I've gotten for this so far -- other than PGP which is apparently
bad -- is "install Signal on your computer in addition to your phone and just
use it as if it's email". That's... not really a satisfactory answer. Like, I
expect a multi-page Signal message talking about everything I've been up to
for the past month to annoy its recipient, who is likely reading it on their
phone, not their computer. And I can't send someone a Signal message about a
paper they wrote that I have some comments on, not unless they're going to put
their fricking _phone number_ on their website.

So what do I do here? The secure email replacement just doesn't seem to be
here yet.

~~~
umvi
I don't get what's insecure about normal unencrypted email. It's sent over
https, isn't it? It's not like I can read your emails unless I break into
Google's servers, no? And even if I do, they probably aren't even stored in
plaintext.

I just don't get the encrypted email obsession. It's impossible for an
individual to withstand a targetted cyber attack so it seems pointless to go
above and beyond to ultra encrypt every little thing

~~~
jcranmer
In modern practice, email is sent over TLS sockets already. Any good email
client should prohibit you from using SMTP, POP, or IMAP with TLS, and for the
past few years, even the MX-MX transfers in the backend have started to become
protected (albeit mostly opportunistically at this point, I believe) with TLS.

So the only people who can read email are you, your counterparty, your ESP,
and your counterparty's ESP, assuming the email providers are following good
practice.

~~~
Godel_unicode
This is an excellent explanation overall, I do however think that it's
important to note that opportunistic STARTTLS is vulnerable to downgrade
attacks by mitm. Since this would have to be a mitm of e.g. Gmail it's not
trivial by any means, but neither is it completely out of reach (see for
example the periodic rerouting of the internet caused by odd BGP
advertisements).

One further note is that you can know post-hoc if an email was delivered to
Gmail via TLS by the presence or absence of a red lock in the Gmail app or web
UI.

~~~
bigiain
> STARTTLS is vulnerable to downgrade attacks by mitm.

Not only that, but intentionally downgrading STARTTLS commands has as times
been the default configuration for some Cisco routing gear.

(Buy me a beer one day and I might tell you about the time I charged one of
Australia's big four banks about $70k to debug that in a router on their
internal network that nobody there knew existed...)

~~~
jlgaddis
Which _routers_ did that? I'm well aware that the ASA firewalls did it ("ESMTP
inspection") -- I've disabled that dozens of times -- but I've never heard of
a router that did it (by default).

------
tialaramex
There's a few places where this engages in goalpost shifting that seems less
than helpful even though I end up agreeing with the general thrust. Let's
focus on one:

> Put a Signal number on your security page to receive bug bounty reports, not
> a PGP key.

We can reasonably assume in 2019 that this "security page" is from an HTTPS
web site, so it's reasonably safe against tampering, but a "Signal number" is
just a phone number, something bad guys can definitely intercept if it's worth
money to them, whereas a PGP key is just a public key and so you can't
"intercept" it at all.

Now, Signal doesn't pretend this can't happen. It isn't a vulnerability in
Signal, it's just a mistaken use case, this is not what Signal is for, go ask
Moxie, "Hey Moxie, should I be giving out Signal numbers to secure tip-offs
from random people so that nobody can intercept them?".

[ Somebody might think "Aha, they meant a _Safety number_ not a Signal number,
that fixes everything right?". Bzzt. Signal's Safety Numbers are per-
conversation, you can upload one to a web page if you want, and I can even
think of really marginal scenarios where that's useful, but it doesn't provide
a way to replace PGP's public keys ]

Somebody _could_ build a tool like Signal that had a persistent global public
identity you can publish like a PGP key, but that is not what Signal is today.

~~~
dunkelheit
> > Put a Signal number on your security page to receive bug bounty reports,
> not a PGP key.

Does anyone actually do this? Even Signal developers themselves don't! (see
[https://support.signal.org/hc/en-
us/articles/360007320791-Ho...](https://support.signal.org/hc/en-
us/articles/360007320791-How-can-I-report-a-security-vulnerability-)). Instead
there is a plain old email address where you are supposed to send _your_
Signal number so that you can chat.

~~~
tptacek
We manage bug bounties for a bunch of different startups, and I can count on
zero fingers the number of times I've had to use PGP in the past year for
that. In practice, people just send bugs with plain 'ol email.

~~~
nmadden
I used to get about 1 or 2 PGP-encrypted emails with security bug reports per
year when I managed this for my employer. There's a dedicated team that
receives security reports now, with email feeding into an automated ticketing
system with automatic acknowledgements, reminders, spam filters, PagerDuty
alerts, etc. There's a huge amount of tooling and workflow built around email,
with a lot of integrations into all kinds of enterprise software. Often the
only sane way to trigger all this stuff is to send an email.

So I think the result of removing PGP will be even more plain 'ol email than
anything else.

~~~
lvh
It sounds like you’re saying “and that’s why GPG is good”, but I read that as
an argument why there’s a very high probability that one of those things is
going to spill the beans, plaintext, in an email anyway.

~~~
nmadden
No, I'm not defending PGP. Even without the automation, every PGP-encrypted
email almost certainly results in a bunch of internal plaintext emails between
employees that could easily accidentally cc the wrong person, etc. I'm just
pointing out that the chances of replacing PGP with something genuinely secure
for these kinds of use-cases are close to zero.

------
jeroenhd
Whent talking about alternatives, Signal and WhatsApp get mentioned because
they're easy to use. They are. Signal is pretty secure. WhatsApp probably is
as well but we can't be sure. That is, until it isn't anymore.

WhatsApp already has a key extraction protocol built right in for its Web
interface. Signal has a web (Electron) interface as well, and a shitty one at
that, where the messages also get decrypted. For WhatsApp, this means you're
one line of code away from Facebook extracting your private keys.

Signal is different, in that they're not a for profit company. However,
they've shown in the past that they are under no circumstances willing to
allow support of any unofficial client or federate with another. In fact,
they've taken steps against alternative clients on the past, making it clear
that only their client is allowed to use the signal system. The moment the
signal servers go out, Signal becomes unusable. This also leaves signal in the
same position as WhatsApp, where we are dependent on one person compiling the
app and publishing it on whatever app store you prefer. If signal has any
Australian contributors and their code review fails sufficiently this means
you're basically toast the moment the Australian government gets annoyed at a
particular signal user enough.

Very few real alternatives to PGP exist. PGP is not just a message encryption
format, it's a _federated_ message encryption format. There are very few
actual federated message standards that come close to the features PGP
supports. There's S/MIME, but that's only available after paying an expensive
company for it to be of any use because it's validated as a normal TLS
certificate and the free vert providers don't do S/MIME.

If all of these "real cryptographers" disagreeing with PGP's design would
design a new system that can be used the same way PGP is used, I'm sure we'd
see that getting some good usage figures quite quickly. But all alternatives
seem to focus on either signing OR encrypting OR the latest secure messaging
app instead of a PGP replacement.

~~~
txcwpalpha
>WhatsApp already has a key extraction protocol built right in for its Web
interface.

I don't believe this is correct. WhatsApp (and Signal AFAIK) web works by
decrypting the original message on your phone, re-encrypting it with a
different key that is shared with your web interface (this is what is being
shared via the QR code when connecting to WhatsApp Web), sending it to the web
client, and having your web client use the second key to decrypt. This is why
your phone must continue to be powered on/connected to the network for the web
service to work. The original key is never "extracted", and AFAIK can't be
extracted by normal means.

There are a few apps that attempt to exploit a few security vulnerabilities to
recreate your key for you if you lose it and need to access backups, but that
isn't the same as what you're describing.

~~~
newscracker
WhatsApp always requires your phone to be around, whereas Signal needs it only
when you link it. After linking, the desktop client is independent of the
phone (being online or in your vicinity or the number being in your
possession).

~~~
txcwpalpha
Yep, you're right. I just looked more into it and WhatsApp and Signal operate
differently. WhatsApp works as I described, but Signal actually does share the
original key between all devices through some sort of key sharing mechanism.

------
bennofs
I understand that there are better tools for encryption, but is there anything
that replaces the identity management of PGP? Having a standard format for
sharing identities is necessary in my opinion. If I have a friend (with whom I
already exchanged keys) refer me to some third friend, it would be nice if he
can just send me the identity. Sending me the signal fingerprint isn't a
solution for two reasons:

\- I don't want to be manually comparing hashes in 2019

\- it locks me into signal, I wont be able to verify a git commit from that
person as an example

Is there a system that solves this? Keybase is trying but also builds on PGP,
we can use S/MIME which relies on CAs but is not better than PGP. Anything
else?

~~~
mike_hearn
The CA system is strictly better than PGP for identity management in every
respect.

People often think it must be the opposite but this is essentially emotional
reasoning: the Web of Trust feels decentralised, social, "webby"
un"corporate", free, etc. All things that appeal to hobbyist geeks with
socialist or libertarian leanings, who see encryption primarily through the
activist lens of fighting governments / existing social power structures.

But there's nothing secure about the WoT. As the post points out, the entire
thing is theatre. Effectively the WoT converts every PGP user into a
certificate authority, but they can't hope to even begin to match the
competence of even not very competent WebTrust audited CAs. Basic things all
CAs are required to do, like use hardware security modules, don't apply in the
WoT, where users routinely do unsafe things like use their private key from
laptops that run all kinds of random software pulled from the net, or carry
their private keys through airports, or accept an email "From" header as a
proof of identity.

I wrote about this a long time ago here:

[https://blog.plan99.net/why-you-think-the-pki-
sucks-b64cf591...](https://blog.plan99.net/why-you-think-the-pki-
sucks-b64cf5912aa7)

~~~
jancsika
> But there's nothing secure about the WoT.

I haven't read your blog, but this sentence unfairly paints WoT with PGP/GPG's
problems.

It's completely reasonable to have a WoT that operates correctly when at least
a _single_ participant isn't completely incompetent. That's how git works.

I haven't looked closely but I'd be willing to speculate that PGP is to WoT
what C++ is to fast compile times.

~~~
jancsika
Just to drive the point home, compare:

* the amount of time some pedants waste at a PGP "key party"

* the time it takes me to accept a merge request from someone who made a commit in the gitlab UI using Internet Explorer on their grandparents' malware-laden Dell desktop

Both examples leverage WoT.

Edit: hehe I wrote PGP "key party" instead of "key signing party."

------
luizfelberti
The missing answer in there is how to avoid PGP/GnuPG for commit signing. I've
asked about this in another similar thread[0] but didn't get a hopeful answer.

Everytime I look at git's documentation GPG seems very entrenched in there, to
a point that for things that matter I'd use signify on the side.

Is there a better way?

[0]
[https://news.ycombinator.com/item?id=20379501](https://news.ycombinator.com/item?id=20379501)

~~~
paulddraper
Signing tags (or somewhat less usefully, commits) can be done the same way
packages are signed. It might not be directly integrated with git, but it
wouldn't be hard to make a good workflow.

The article mentions Signify/Minisign. [1]

[1]
[https://jedisct1.github.io/minisign/](https://jedisct1.github.io/minisign/)
as an PGP alternatie.

~~~
gocartStatue
> It might not be directly integrated with git

That's the problem I see. I have signingkey in .gitconfig, together with
[commit] gpgsign = true. This way, set & forget, all my commits are signed
(it's my employer requirement, probably some "compliance" stuff). You can see
it right away nicely displayed as "Verified" on github. I didn't know about
GPG-s supposedly weak security until now, but always considered it not very
convenient to use.

~~~
paulddraper
Ah, well if your employer mandates PGP signatures on every commit, that's
that.

FWIW, the creator of git argues that signing of every commit is essentially
pointless. [1] I agree.

[1] [http://git.661346.n2.nabble.com/GPG-signing-for-git-
commit-t...](http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-
td2582986.html)

------
upofadown
So the suggested solution for more secure email is just to give up on the
concept of email entirely? Anything that does not do perfect forward secrecy
is just pointless so there is no point in trying to keep significant
discussions to refer to later. We are expected to return to a sort of virtual
pre-writing stage.

This is not really helpful. For all its shortcomings, PGP is pretty much all
we have. If used in a straightforward way it actually can protect email from
nation state level actors for a significant time. That's gotta count for
something.

~~~
swalladge
I know right - they are all recommending Signal, Wire, WhatsApp, etc., but
these aren't alternatives. They are all centralized, controlled by a single
entity even if the underlying protocols are open. And you're right, they are
instant messaging - ie. alternatives to Messenger, Hangouts, etc.

We need a modern email replacement that is decentralized, federated, et al.
Something that keeps all the modern cryptographers happy, while facilitating
the same kind of long form conversations and federated self-hostability that
email provides.

I think Matrix is getting there, but even that is still focused on instant
messaging.

~~~
Natanael_L
As I've mentioned in another thread, I think we're more likely to get there
via the route of E2EE documents collaboration tools. Something that cleanly
breaks away from the email model, and adds enough value to make the switch
worth the effort.

------
belorn
Telling people to treat email as insecure and thus not use it for anything
serious is terrible bad advice.

I am reminded of BGP (Border Gateway Protocol). Anyone who has even glanced at
the RFC of BGP could write an essay of the horrible mess of compatibility,
extensions, non-standard design of BGP. It also lack any security
consideration. The problem is that it is the core infrastructure of the
Internet.

Defining something as insecure with the implied statement that we should treat
it as insecure is unhelpful advice in regard to critical infrastructure.
People are going to use it, continue to use it for the unforeseeable future,
and continue to treat it as secure. Imperfect security tools will be applied
on top, imperfectly, but it will see continued used as long as it is the best
tools we have in the circumstances. Email and BGP and a lot of other core
infrastructure that is hopelessly insecure will continue to be used with the
assumption that they can be made to be secure, until an actually replacement
is made and people start to transition over (like how ipv6 is replacing ipv4
and we are going to deprecate ipv4 if you take a very long term view of it).

~~~
tptacek
People that use email to convey sensitive messages will be putting themselves
and others at risk, whether or not they use PGP, for the indefinite future.
That's a simple statement of fact. I understand that you don't _like_ that
fact --- nobody does! --- but it remains true no matter how angry it makes
you.

~~~
belorn
I would say that people that use any critical infrastructure not designed with
security in mind is putting themselves and others at risk if they convey
sensitive information. This is why plain text protocols should be considered
insecure.

It would be great if we could replace the whole Internet with modern
technology rather than relying on ancient systems like BGP and email.

~~~
tptacek
How do you write this after writing that previous comment, which says that
what I just wrote is "terrible bad advice"?

~~~
belorn
Telling people to stop using the Internet because it is insecure is bad
advice. It is extremely unrealistic, like telling people to stop using cars
and trucks because driving kills people every year.

However suggesting that we should change things to eliminate the risk is good.
We could eliminate car accidents completely if everyone went over the
automatic driven cars that communicated as a mesh network. The Swedish "zero
vision" could be achieved, maybe even with todays technology, but it would be
a massive undertaking.

Replacing BGP would be a similar massive undertaking. Just switching away from
ipv4 to ipv6 has so far taken 20 years and we have no date in sight when we
can start deprecating ipv4. From what I have heard/seen, a lot of people are
somewhat reluctant to issue backward incompatible replacements of core
infrastructure because they look at ipv6 and fear that kind of process. Even
seen some pessimistic talks that argue that it is impossible and the only way
to achieve changes in core infrastructure is with incremental changes that are
fully backward compatible. I am not really of the view but I do understand
their fear.

My advice to people is not to abandon email, even if I doubt much people would
heed to the warning that email is unsafe for government, business, people and
their family. People will risk it regardless. Thus I focus on what may help,
imperfect as those may be. In the past that was PGP in the form of enigma mail
plugin. Today I am keeping an eye on the new pretty Easy privacy which
hopefully can outsource the security to a library that attempts optimistic
encryption when ever possible.

~~~
tptacek
The PGP team openly and enthusiastically discusses how they've advised
dissidents in places like Venezuela, about which just recently the NYT ran an
expose of death squads sponsored by the Maduro administration. What they're
telling dissidents to do _has to work_. It _demonstrably doesn 't_. Pretending
otherwise, because everyone else does it, is malpractice. I don't understand
where the wiggle room people are finding on this issue is.

~~~
belorn
The only advice you can semi-safely give to dissidents that face state
organized death squads is to hide and get new identities, and never ever
reveal the old ones to anyone.

Signal will not make people immune to death squads, nor will any other
technology. It was not that long time ago that members of Anonymous went after
the cartel and we got pictures of people tortured and killed. It only take one
trusted person who know a dissidents real identity or family or friends or
community for things to get very ugly very fast.

If the PGP team promised security against state organized death squads then
that's their fault. Pretending that technology will protect you against that
kind of threat can be a very costly mistake.

------
cyphar
I would suggest using restic over TarSnap for encrypted backups -- it gives
you more flexibility with where your backups will be stored since TarSnap is
pretty integrated with Colin Percival's online service and is also
unfortunately not free software. But it's also an as-simple-as-possible
cryptosystem. Filippo did a quick lookthrough and said that it seemed sane
from a crypto perspective[1].

[1]: [https://blog.filippo.io/restic-
cryptography/](https://blog.filippo.io/restic-cryptography/)

~~~
always4getpass
Any opinions about rclone?

It seems to be fine for my mediocre backup needs

~~~
cyphar
rclone is fine (in fact I use rclone with restic to synchronise my restic
backup repository on BackBlaze B2) but it doesn't encrypt or deduplicate your
backups -- it's just a synchronisation tool like rsync.

~~~
always4getpass
What about its 'crypt' encryption backend?

Afaik it uses scrypt which was designed for tarsnap

~~~
cyphar
Ah, I wasn't aware it had an encryption backend. Just looking at the
documentation I'm quite worried -- why on earth is there an "obfuscate" mode?

I would suggest using restic. It doesn't have any weird modes, it simply
encrypts everything and there isn't any weird need to specify (for instance)
that you want things like metadata or filenames encrypted. Also backups are
deduplicated using content-defined-chunking -- giving you pretty massive
storage savings. If you really need rclone since it supports some specific
feature of your backend -- restic supports using rclone as a synchronisation
backend (or you can do what I do, which is to batch-upload your local restic
backup every day).

~~~
namibj
It's a choice between plaintext filenames or no plaintext filenames.

You might want to crypt your nudes, but still access normal pictures
unencrypted through the provider's web interface.

------
tedunangst
I am a combination of honored and terrified that signify is the leading
example for how to sign packages. The original goals were a bit more modest,
mostly focused only on our needs. But that's probably what's most appealing
about it.

~~~
tptacek
I think you should get comfortable with that, because all the opinions I've
collected seem to be converging on it as the answer; Frank Denis Frank-Denis-
i-fying it seems to have cinched it. Until quantum computers break
conventional cryptography, it would be downright weird to see someone design a
new system with anything else.

------
teythoon
We over at Sequoia-PGP, which gets a honorable mention by the OP, are not
merely trying to create a new OpenPGP implementation, but to rethink the whole
ecosystem.

For some of our thoughts on the recent certificate flooding problems, see
[https://sequoia-pgp.org/blog/2019/07/08/certificate-
flooding...](https://sequoia-pgp.org/blog/2019/07/08/certificate-flooding-sks-
gnupg-issues-the-sequoia-project/)

~~~
lucb1e
The homepage has some meaningless marketing bullet points about the greatness
of pgp itself. Where would I find the ways in which you rethink the whole
ecosystem? It seems like Sequoia is just a library, not even a client.
Wondering how this could change pgp by much if at all.

------
stubish
The PGP problem isn't going away until there is a stable alternative. Under
'The Answer' there are several different, domain specific tools, with their
different features and UIs and limitations. And the general case (encrypting
files, or really that should be 'encrypting data'), "this really is a
problem". If I want to replace my use of GnuPG on production with the things
on that list, I need to write my own encrypt/decrypt wrappers using libsodium
and hope that future travellers can locate the tool or documentation so they
can decrypt the data. So I stick with the only standard, GnuPG, despite
acknowledging its problems.

~~~
tptacek
What specific problem are you trying to solve with PGP? If it's "encrypting
files", why are you encrypting those files? What's the end goal? I acknowledge
that there are cases that boil down to "encrypt a file", but believe they are
a lot narrower than people assume they are.

~~~
stubish
We encrypt files:

\- For offsite backups (disaster recovery), mirroring object stores and
filesystems to cheap cloud storage.

\- For encrypting secrets needed for maintaining IT systems (eg. all those
shared passwords we never seem to be able to get rid of)

\- For encrypting sensitive documentation for transfer (email attachment,
shared via filesystem, shared via HTTP, shared via pastebin even)

Despite the awful UI, GnuPG does all of that in a standard way. We have tested
disaster recovery with no more instructions than 'the files are in this S3
bucket'.

And the same tool is also useful for other tasks too: \- public key
distribution (needs care to do it securely, but functional) \- commit signing,
signed tags \- package signing (per Debian)

We could use custom or multiple tools for all this, but a single tool to learn
is a big advantage.

I think all use cases boil down to 'encrypt and/or sign a file' for one of the
stages. In the article, 'talking to people', 'sending files', 'encrypting
backups' are all really just 'encrypt/sign a file' followed by transmission.
And some sort of keyring management is needed for usability. A tool that can
pull keys from a repository and encrypt and/or sign a file to a standard
format could be used to build all sorts of higher level tools. I imagine it
would be quite possible to build this on top of libsodium, and if it gained
mindshare, replace uses of GnuPG.

~~~
cyphar
> I think all use cases boil down to 'encrypt and/or sign a file' for one of
> the stages. In the article, 'talking to people', 'sending files',
> 'encrypting backups' are all really just 'encrypt/sign a file' followed by
> transmission.

But they aren't the same thing. That's the whole point the article is making.
Yes, if all you have is a tool that does "encrypt+sign a file", then all
crypto problems will look like "encrypt+sign a file" problems.

For backups, tools like restic provide deduplication and snapshots as well as
key rotation (and restic works flawlessly with dumb S3-like storage). You
can't do that with PGP without reimplementing restic on top of it. Same with
TarSnap. For talking to people, you want perfect forward secrecy and (usually)
deniability. PGP actively works against you on both fronts. For sending files,
there are also other considerations that Wormhole handles for you (though to
be honest I haven't used it in anger).

While you can "solve" these problems with one tool, the best way of solving
them is to have separate tools. That's the point the article is making.

~~~
PeterisP
For securely talking to people, often you may want non-repudiation, which is
the exact opposite of deniability and anonymity.

There are very different, incompatible needs for slightly different usecases.

~~~
cyphar
Signal -- and all other OTR-like protocols -- have deniability (or if you
prefer it has repudiation rather than non-repudiation). Neither conversation
participant can prove to a third party that the other party said something in
a conversation. Moxie wrote a blog post about this in 2013[1].

The only circumstance in which you want non-repudiation is if you are really
sure that you are okay with the recipient of your message later posting
cryptographic proof that you said something in a chat with them. I bet most
people (if you asked them) would effectively never want that "feature" for
private chats.

[1]: [https://signal.org/blog/simplifying-otr-
deniability/](https://signal.org/blog/simplifying-otr-deniability/)

~~~
PeterisP
Sure, you usually don't want that feature in private setting, but you almost
always want that feature in a commercial setting, and lots of communication
happens in that context.

E.g. vendor-customer helpdesk chat, internal workplace communication including
"less internal" things like different subsidiaries of international companies,
etc, etc. Half of financial world runs on Thompson Reuters messenger which is
essentially glorified chat. What if your boss sends you a message "hey, do
that risky thing right now" \- do you want that (likely informal) means of
communication to have deniability? Does the company want deniability in the
app in which random middle-managers message their subordinates? It makes sense
for companies to mandate that teams choose only communications platforms that
support authentication and nonrepudiation.

As soon as money, any kind of disputes, and the smallest chance for future
legal proceedings are involved, anonymity and deniability are flaws and not
features - as I said above, superficially similar use cases can have opposing
and incompatible requirements.

Even going back to the commonly discussed use case of Signal for journalism.
Let's say a journalist interviews a whistleblower over a mobile messaging app
- you'd want anonymity and deniability there. And five minutes later that same
journalist asks a clarifying question to the official head of that agency,
likely also using a mobile messaging app, possibly the same one. Do you want
the answer of that official to have deniability, or do you want that
journalist to be able to cryptographically prove that the official lied?

~~~
cyphar
I think our main disagreement is the usage of the word "usually". There are
chat systems that have non-repudiation that aren't PGP -- I don't think
there's much more to elaborate.

For personal communications, usually people want deniability. For business-
related communication, you might want non-repudiation.

~~~
PeterisP
Probably the point I'm trying to make is that for me the communication
scenarios seem similar enough, and the line between business and consumer
comunication is so blurry with people using private mobile devices in business
and expecting the same set of tools to cover all their communication, that
saying "oh, there's another tool that does it the opposite way" isn't really a
sufficient answer - perhaps we need to treat it as essentially a "flag" in the
same tool; this useraccount/chatgroup/etc is authenticated and doesn't have
any deniability whatsoever, but in the same app over there I have a
pseudonymous contact with a marker over it that's effectively anonymous with
full deniability and OTR communications.

------
eadmund
Magic Wormhole is neat, but the happy path is to use a third-party rendezvous
server, which is susceptible to traffic analysis (I also wish that the codes
had more than 16 bits of entropy, but that is part cargo-culting on my part).

Signal is also vulnerable to server-side traffic analysis, and is strangely
keen on both demanding a selector (a phone number) for identity _and_ on
trusting Intel's 'secure' enclave (I strongly suspect that it's suborned).

One thing I _do_ like about PGP is that it has been around awhile: I can still
decrypt my old files & verify old signatures just fine, something I don't
trust the flavour of the month to do.

I think that rather than a Swiss Army knife tool & protocol like PGP, we
should have a suite of tools built around a common core, probably NaCL. That
way we can have compatibility when we need it, but also aren't cramming square
pegs into round holes.

Finally, the Web of Trust was a bright, shiny idea — and wrong. But Trust on
First Use is also pretty bad, as is the CA ecosystem. We need something else,
something _decentralised_ and also secure — and I don't think that's
impossible. I've had a few ideas, but they haven't panned out. Maybe someday.

~~~
lvh
Re: common core: isn't that already happening? age and signify are both based
on those 2, and magic-wormhole arguably is too (though point addition is not
always exposed, so SPAKE2 is a little harder to implement than signify).

~~~
eadmund
Yeah-ish, but what I mean is an actual set of different tools (so, not one-
size-fits-all) but all part of the same suite, rather than a bunch of
different implementations of mostly the same idea — i.e., *BSD rather than
Linux.

One of my numerous hobby projects is exactly that, but … I simply don't have
enough Round Tuits.

~~~
lvh
OK, so you're saying something like:

    
    
      magic send <FILE>
      magic receive <CODE>
      magic encrypt <FILE>
      magic sign <FILE>
    

... that ideally all have NaCl at the base but are otherwise one binary that
you have to remember?

The tricky one there is probably chat.

~~~
rakoo
I think they meant something like the OpenSSL binary that obviously builds on
the library and provides everything through the command line.

The problem is that the same thing for NaCl/libsodium would be lower level,
and probably still not enough as exhibited in the article: a typical use case
is not "I want to encrypt this file", it's "I want to send this file to that
person such that no one else can read it" or "I want to send a message to that
person such that no one else can read it, and if they can they shouldn't be
able to read other messages from the same conversation". No cli tool can
properly solve this, it has to be incorporated in the application or even
protocol.

------
tptacek
Really, all I did here was combine posts from Matthew Green, Filippo Valsorda,
and George Tankersley into one post, and then talk to my partner LVH about it.
So blame them.

(also 'pvg, who said i should write this, and it's been nagging at me ever
since)

~~~
book-mind
Is it wrong to use openssl to encrypt files?

0\. (Only once) generate key pair id_rsa.pub.pem, id_rsa.pem

1\. Generate random key

    
    
      openssl rand -base64 32 > key.bin
    

2\. Encrypt key

    
    
      openssl rsautl -encrypt -inkey id_rsa.pub.pem -pubin -in key.bin -out key.bin.enc
    

3\. Encrypt file using key

    
    
      openssl enc -aes-256-cbc -salt -in SECRET_FILE -out SECRET_FILE.enc -pass file:./key.bin
    

\-- other side --

4\. Decrypt key

    
    
      openssl rsautl -decrypt -inkey id_rsa.pem -in key.bin.enc -out key.bin 
    

5\. Decrypt file

    
    
      openssl enc -d -aes-256-cbc -in SECRET_FILE.enc -out SECRET_FILE -pass file:./key.bin

~~~
tptacek
To start with, none of that encryption is authenticated.

~~~
book-mind
So if I understand you correctly (Noob here), Alice would need to sign the
pair (key.enc, file.enc) to authenticate that those files originated from her.

Without that, Bob could potentially receive any pair of (key,file), which
would just decrypt into garbage data.

BTW, variations on that sequence appear all over the internet when searching
for "openssl encrypt file with public key"...

~~~
jcranmer
This is one of the problems with cryptography: with a little knowledge, you
can end up making yourself completely insecure while believing yourself to be
very secure.

People generally imagine that "encrypt this block of data" is a simple
primitive that does everything you want it to. But naive encryption doesn't
work like that. In the worst case, where you use ECB for the block cipher [1],
you end up with the ECB penguin: [https://blog.filippo.io/the-ecb-
penguin/](https://blog.filippo.io/the-ecb-penguin/). Your secure crypto
becomes a pretty trivial Caesar cipher, just on a larger alphabet. Other modes
(such as the CBC mode you used) aren't so bad, but if you have some hint of
the structure of the underlying data, you can start perturbing the ciphertext
to manipulate the encrypted data.

The modern solution to that problem is "authenticated encryption," which means
that you add in an additional guarantee that the ciphertext hasn't been
tampered with. Even then, there is still room for doing things incorrectly
(padding is a real pain!).

[1] This is so bad it shouldn't ever be an option in any tool.

~~~
tptacek
_[1] This is so bad it shouldn 't ever be an option in any tool._

And yet it's effectively the default.

------
trabant00
The problem with the alternatives is they are product specific and baked into
that product. I need a tool that is a separate layer that I can pipe into
whatever product I want, be it files, email, chat, etc. Managing one set of
identities is hard enough thank you very much and I also want to be able to
switch the communication medium as needed.

I use gnupg a lot and I'm certainly not very happy with it but I guess it's
the same as with democracy: the worst system except for the all the others.

~~~
Natanael_L
The problem with this is that a tool that is too generic is itself dangerous,
because it creates cross protocol attacks and confusion attacks like in
[https://efail.de](https://efail.de) for PGP email.

I think that a better approach is to bind identities from multiple purpose
built cryptographic protocols.

~~~
trabant00
If you blame gpg for efail you can blame anything really for a virus on one of
the endpoints of any form of encryption.

Next you will hold rensponsible tech for social engineering and mandate users
should not know their own secrets because that causes vulnerabilities in
protocols :p

~~~
Natanael_L
By that logic we shouldn't recommend cars with high safety ratings, because we
can always train users to drive motorized unicycles at 200 MPH. Clearly
there's no fault with the unicycle regardless of how many people crash, it
behaved as specified.

Except the specification is trash.

~~~
trabant00
Except cars with 5 star rating exist but a better solution than PGP doesn't.

------
mirimir
FYI, Robert J. Hansen's comment in gnupg-users@gnupg.org.[0]

0) [https://lists.gnupg.org/pipermail/gnupg-
users/2019-July/0623...](https://lists.gnupg.org/pipermail/gnupg-
users/2019-July/062384.html)

~~~
tptacek
I don't understand how these represent "mistakes", let alone "serious
mistakes". But I'm glad he liked it.

~~~
mirimir
It's over my head, but I thought that a reference would be useful. Given that
the mail list thread references HN.

~~~
tptacek
Oh, no, sorry, I'm glad you posted this; I wouldn't have known where to look.
Thank you!

------
ekianjo
So the recommendation here is just to use Chat clients to communicate and
forget about Email? Well that is hardly a good solution.

~~~
lvh
Yes! E-mail is fundamentally terribly positioned to do secure messaging. You
can use e-mail, or you can have cryptography that works and have people use
it, but you can't do both.

~~~
frutiger
> E-mail is fundamentally terribly positioned to do secure messaging

E-mail is fundamentally a way to send a sequence of bytes somewhere
(untrusted) so they can be picked up later by someone (trusted).

That’s also literally what Signal is built on so I think you’re overstating
the difference.

~~~
lvh
Secure messaging is much more complex, but here’s a simple example of how
that’s not true: TCP is bidirectional and email is one message, fire and
forget. That immediately affects your ability to have forward and backward
secrecy.

~~~
frutiger
I do not think the OSI model is very useful but you seem to, so let me put it
this way: E-mail is bidirectional too just at layer 4 instead of layer 3 (I
hope I remembered my layers right!)

E-mail is store-and-forward just like TCP is; how do you think an IP router
works? TCP is fully duplex; a tx doesn’t wait behind an rx, exactly like an
e-mail reply not waiting behind an e-mail receive. The only difference is that
a router will typically use volatile memory to store messages before they are
sent but e-mail will typically use disk.

If your security model relies on this difference then your security model is
broken. It’s worth noting that Signal does NOT rely on this difference. It
relies on participants being mostly online to permit frequent rekeys and not
having to retain old keys indefinitely.

~~~
loup-vaillant
No, email is _not_ bidirectional. You send an email, the recipient later opens
it. Sure, the recipient's SMTP _server_ might respond right away with an
ephemeral key you can use to enjoy forward secrecy, but that server has to
store the message for the recipient to retrieve later.

You can't have full forward secrecy with email as it is used today. If you
want forward secrecy with email, you need _three_ emails sent in rapid
succession: Alice sends a request to Bob, Bob sends a response to accept the
request, and Alice sends the actual encrypted email. That would work. But you
basically need Bob to be online.

~~~
frutiger
> you need three emails sent in rapid succession

This is partially correct, but they do not need to be in rapid succession, and
therefore Bob does not need to be online.

~~~
loup-vaillant
Alice's ephemeral private key must be kept as long as the whole handshake.
Bob's is a bit shorter (between the last two messages).

If the messages are slow to come, those ephemeral keys become less and less
ephemeral, and could actually be stolen.

~~~
frutiger
That is exactly correct. As I'm sure you know, it is Alice that retains her DH
key not the email server or anyone else. As I said:

> If your security model relies on this difference then your security model is
> broken. It’s worth noting that Signal does NOT rely on this difference. It
> relies on participants being mostly online to permit frequent rekeys and not
> having to retain old keys indefinitely.

Signal does not depend on TCP being "bidirectional" as lvh said, it depends on
participants being mostly online. This has nothing to do with the transport
properties of e-mail vs. TCP.

~~~
lvh
“Bidirectional”. So peers can mostly talk to each other. Do you really want to
die on that particular semantic hill? “These Ethernet frames have source and
destination addresses eventually”?

~~~
frutiger
> Do you really want to die on that particular semantic hill?

Sure. The world of cryptography software is already muddled by misinformation,
poor practices and misguided appeals to authority. We shouldn't need to spread
misinformation about technologies such as e-mail to get people to stop using
it.

------
Leace
> Long term keys are almost never what you want. If you keep using a key, it
> eventually gets exposed. You want the blast radius of a compromise to be as
> small as possible, and, just as importantly, you don’t want users to
> hesitate even for a moment at the thought of rolling a new key if there’s
> any concern at all about the safety of their current key.

Interestingly some protocols such as roughtime use the same tactic as OpenPGP:
one long-term identity key that can be kept offline and rotation of online
(short-term) keys signed by the long-term key. Details here:
[https://roughtime.googlesource.com/roughtime/+/HEAD/PROTOCOL...](https://roughtime.googlesource.com/roughtime/+/HEAD/PROTOCOL.md#certificates)

~~~
lvh
If you squint enough, that’s how CAs work too.

------
Leace
> there’s a simple meta-problem with it: it was designed in the 1990s, before
> serious modern cryptography

SSL was designed in 1994 but it has been properly maintained and today no-one
argues that TLS should be replaced by noise/strobe etc. OpenPGP's problem no
1. is that there are no parties using it on a wider scale and interested in
improving it.

~~~
tptacek
SSL 2.0 was overhauled (by cryptographic experts) to create TLS, and, after
something like 10 years of effort, support for SSL 2.0 was scourged off the
Internet. And still, we had the DROWN attack a couple years ago, which manages
to exploit cross-protocol attacks between SSL 2.0 and TLS _on different
servers_. In the last few years, we got TLS 1.3, which again made significant,
breaking changes with the previous versions of the protocol (such as getting
rid of the RSA handshake), and presumably over the next 10 years we'll be
shedding support for all previous versions of TLS.

That's what didn't happen with PGP.

~~~
Leace
> That's what didn't happen with PGP.

Yes. And your software suggestions are excellent for 2019. I just wonder
whether in 10 years it would be better to have a standard improved/developed,
instead of a collection of one-vendor tools where the code is specification.
That said I don't have high hopes for PGP given its maintenance problem.

Thanks for writing on the subject, even if the subject should already be clear
to majority of technical people!

------
mikorym
First of all, if you are signing something and want to prove that you are the
author, then PGP will allow you to do that.

If you want to encrypt something and prove you are the author, PGP will still
allow you to do that.

Does the author mean that PGP is bad for email specifically?

Excel has many of the mentioned properties, such as backwards compatibility
and inefficiency, but it gets the job done and you bet it will pay your bills.

It feels to me like these posts are like the 80:20 problem, but rather with
99:1 and it's all about that 1%. I understand that software developers should
use libsodium. But I'll sign the words "U R A >on" right now in GPG and wait
for you to break my key and sign "U R 1 2" with my private key...

~~~
lunchables
Yeah, most (all) of these arguments seem silly. The primary argument not to
use it in emails because someone MIGHT improperly quote your email in a reply
and then NOT encrypt their response? Well someone might screenshot your Signal
app, or have malware on their phone, or a million other things. It seems like
such an absurd corner case to me.

For my use case I don't have any concerns about using GPG. I encrypt files
with it, and if anyone wants to put up any money that they can access my
files, let me know what escrow service you want to use.

~~~
riking
Not because it "MIGHT" happen, because it does happen.

~~~
lunchables
I mean "might happen" in any particular instance. Not that it has never
happened and only "might" in the future. Because
0.000000000000000000000000001% of messages have been accidentally exposed does
not make PGP inherently bad.

------
davidcollantes
With PGP I can encrypt/decrypt/sign files, and text. It is widely available in
every platform. The day a single tool comes around that does that, better, I
will switch.

------
taeric
I don't understand why the use of Yubikeys for a non-exportable key isn't
valid for folks that care about security. I mean, I get that not everyone will
use it. The vast majority won't. However, the vast majority don't care about
security at this level. So... what is the actual criticism? If you care about
security, use the keys, right? That feels no different from "use some other
product."

~~~
dchest
The only thing in this world more complicated than setting up GPG is setting
up GPG with Yubikey.

The fact that I have `fix-gpg` script to restart gpg-agent somewhere in $PATH
that I run when for some reason it can't find my YubiKey tells me that it's
not a viable solution for 99% of people.

PS. Actual command from GPG:

    
    
      > help
      ...
      sex     change card holder's sex
      ...

~~~
dewyatt
This is more an issue with GnuPG though, not OpenPGP.

Also, you may want to try using an actual OpenPGP Card ([https://www.floss-
shop.de/en/security-privacy/smartcards/13/...](https://www.floss-
shop.de/en/security-privacy/smartcards/13/openpgp-smart-card-v3.3)). (You can
get a small one inside a USB token too)

------
srl
First, thanks enormously for writing this -- and for all the other recent
articles that have appeared here the vein of "PGP is as bad as it is
unpleasant to use". It's a point I didn't really appreciate (at least as much
as I (sh/c)ould have) and I'm sure I'm not alone.

It seems that the state of package distribution for many distributions is
poor, security-wise. (OpenBSD, to nobody's surprise, is an exception.) For
instance, archlinux (I'm loyal) signs packages with PGP[1] and, for source-
built packages, encourages integrity checks with MD5. My recollection is that,
about 5 years ago, MD5 was supposed to be replaced with SHAxxx. Am I
misinterpreting this? Is this actually Perfectly Okay for what a distro is
trying to accomplish with package distribution?

(I'm particularly suspicious of the source-built package system, which
consists of a bunch of files saying "download this tarball and compiler. MD5
of the tarball should be xyz." I'm pretty confident that's not okay.)

Okay, now moving from package distribution to messaging, and again looking at
the state of my favorite system. How am I supposed to message securely? The
best nix messaging tools are all based around email. Even when I can get the
PGP or S/MIME or whatever toolset to work (let's face it, that's at least 45
minutes down the drain), it's clear that I'm not in good shape security-wise.

I should use signal, apparently. Great. Just a few problems: (1) no archlinux
signal package, (2) I'm guessing I can't use it from the terminal, and (3)
most severely, it seems signal has incomplete desktop support. In particular,
I need to first set up signal on my phone. Well, let's face facts: I have a
cheap phone from a hard-to-trust hardware vendor, and I think there's a >5%
chance it's running some sort of spyware. (The last phone I had genuinely
_did_ have malware: there were ads showing in the file manager, among other
bizarre behaviors.) So in order to use signal on my desktop, I need to buy a
new phone? That's even worse, usability-wise, than PGP.

Is... is it really this bad? I'm getting the sense that the desktop linux
community has completely dropped the ball on this one. (And perhaps more
generally desktop mac/windows... I wouldn't know.)

[1] Perhaps not so bad, since the keyring is distributed with the system --
but how was the original download verified? Options are: PGP, MD5, SHA1, with
the choice left up to the user. That can't be right.

~~~
cyphar
Arch Linux's pacman is not a good example of a secure package distribution
system (especially not the AUR, where you are downloading all the bits from
the internet and building them yourself as your own user or even sometimes as
root). They didn't do any package signing or verification at all until
(shockingly) recently -- less than 10 years ago IIRC. I am a huge fan of
Arch's philosophy but am definitely not a fan of the design of their package
distribution system.

If you look at systems like Debian-derivatives or RPM-based distros
(openSUSE/SLES, and Fedora/CentOS/RHEL) the cryptosystems are far better
designed. In the particular case of openSUSE, the AUR-equivalent (home:
projects on OBS) are all signed using per-user keys that are not managed by
users -- eliminating almost all of the problems with that system. Yeah, you
still have to trust the package maintainer to be sure what they're doing, but
that should be expected. I believe the same is true for Fedora's COPR.

[Disclaimer: I work for SUSE and contribute to openSUSE.]

~~~
Leace
If you have to trust the package maintainer what's the difference between
having package signed by them or not?

For the record AUR packages can use GPG keys, see e.g. GPGKEY variable:
[https://wiki.archlinux.org/index.php/Makepkg#Configuration](https://wiki.archlinux.org/index.php/Makepkg#Configuration)

Arch also uses Web of Trust to introduce Trusted Users:
[https://www.archlinux.org/master-keys/](https://www.archlinux.org/master-
keys/) so I wouldn't call "less than 10 years" as a disadvantage, but rather
advantage - they have seen problems with alternative designs (e.g. Debian's
curated keyring) and came up with something better.

------
lucb1e
For backups, I would recommend Restic. The author mentions Tarsnap, and if you
don't want to back up five terabytes that is probably great, but after a few
gigabytes it's just not economical for private persons. If you're on hacker
news (i.e. the 'engineer' the author was talking about), odds are that storing
a hard drive connected to a raspberry pi at your parents' and using Restic as
client is an extremely cheap way of backing up many terabytes securely.

~~~
wbl
I have a few gigabytes on tarsnap for pennies a day.

~~~
lucb1e
Hence "after a few gigabytes".

------
fipar
So, as a technical person (I can write and debug software, deploy it to
production, etc.) but only an end-user when it comes to cryptography:

What are the biggest weakenesses of using PGP for local file encryption?

My use case is I have a 'vault' of secrets that I store in a gpg-encrypted org
file, with a key binding in emacs to let me easily decrypt this 'vault'.

The encryption is done with gnupg's symmetric encryption, i.e., just me typing
a passphrase, not using my private key. This encrypted file resides in a
Filevault-encrypted drive, and is backed up to a an encrypted TimeMachine
backup. It never leaves my local drive or the external USB drive I use for
backups (at least not that I know of).

What are my biggest risks here? I did not get much info from the article on
this use case other than "perhaps wait for age". I understand I could be using
an encrypted volume that I mount on demand, which I already do for other use
cases, but that would get rid of the convenience of having this "vault"
available to me just one emacs shortcut away. I'm willing to give that up if
the risks are big enough but I'm kindly asking the knowledgeable HN audience
for advice to see what I'm doing is really that bad.

~~~
yitosda
There's nothing wrong with this. Public/Private keys are for sharing secrets
and proving identity.

Assuming you are using a sane cipher and mode, your risks boil down to any of
a myriad of methods of stealing/bruteforcing your key or grabbing the
unencrypted file.

~~~
fipar
Thanks!

------
progx
Messenger are not easier than email, only when 2 ore more communicate on one
topic.

But with email you communicate with one or more people about many topcis.

To archieve the same structure in a messenger, you must create several
discussions. So messenger are not the holy grail of communication, that is why
people still use email.

We need an email user interface with open messenger protocols under the hood
for secure communication and usability. None of the current messenger offer
that.

~~~
goffi
For a proof of concept, I've made a couple of years ago a "gateway" which was
launching a local IMAP server in my XMPP client. This way you could use any
MUA you like while taking profit of XMPP infrastructure (JID — XMPP identifier
— are similar to email addresses) and its encryption (OMEMO can be used with
that for instance). In other words, you could send messages from Thunderbird
(or Gajim) to KMail by using only XMPP protocol (and thanks to IMAP Push, you
got notifications immediately).

------
terom
> Encrypting Files > This really is a problem. If you’re/not/ [...] then
> there’s no one good tool that does this now. Filippo Valsorda is working on
> “age” for these use cases, and I’m super optimistic about it, but it’s not
> there yet.

I've been (ab)using ansible-vault for this. It's apparently[1] now using
reasonable primitives (PBKDF2+AES-CTR+HMAC-SHA256), but not necessarily the
latest and bestest ones:
[https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/p...](https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/parsing/vault/__init__.py#L1108)

The implemention is sub-optimal though, with some silly issues that haven't
been fixed like
[https://github.com/ansible/ansible/issues/12121](https://github.com/ansible/ansible/issues/12121)

[1] [http://toroid.org/ansible-vault-strange-
crypto](http://toroid.org/ansible-vault-strange-crypto)

~~~
fanf2
I have some notes on why I (and some of my colleagues) use gpg instead of
Ansible vault:
[https://dotat.at/prog/regpg/doc/rationale.html](https://dotat.at/prog/regpg/doc/rationale.html)

I would dearly like a replacement for gpg in this context; `age` by Filippo
Valsorda and Ben Cartwright-Cox looks like it will be nice, though I would
like it to be easier to audit the recipients of encrypted files. Note that
this kind of auditing relies on an information leak that cryptographers
usually try to suppress...

------
elagost
With the rapid churn of various chat clients it's hard to get something to
stick, and I attempted to settle on XMPP+OMEMO (or OTR), since it's a
protocol, not an "app" (eww). Not a single person I know still uses XMPP, and
it's easier to just tell people "Download Signal". However, that requires a
phone number, and is useless on a desktop if your phone's off. Despite being
Free Software, it's fairly locked down.

Secure communication with most people is nigh impossible these days, because
nobody wants to not use SMS.

There has to be a better solution, and despite email+PGP's flaws, it's the
only system I've seen that's stood the test of time. There are pretty good
plugins for Mail.app (macOS) and Outlook (Windows), and if you use Linux you
probably can deal with gpg. We use it at work for email, and pretty much
everyone can work with it at any level of technical expertise. Anyone else
have any solutions that have worked in their circles, including non-technical
family members?

~~~
lorenzhs
Signal Desktop has never required your phone to be on. It's completely
independent once set up (apart from the occasional contact list sync). It has
been this way since the first version of Signal Desktop. You're probably
thinking of WhatsApp Web, which works the way you describe. I've seen this
incorrect information spread on HN too many times, and I'm not sure how so
many people came to think that. It's been 100% wrong from the beginning.

~~~
elagost
You are correct. Thanks for pointing that out; I tested it out this morning
and verified I was able to send/receive messages on the desktop program with
my phone in airplane mode.

------
maufl
I use my PGP key (with a Yubikey) for two things, the pass password manager
and as an SSH authentication key. Is there a replacement for those two use
cases where I can store my private key on a hardware token?

~~~
tptacek
I use the GPG compatibility goo to get an SSH key out of my Yubikey 5 and
that's fine, it's fine, go ahead and do that.

------
jedisct1
PGP was a game changer when it was introduced and the idea of a chain of trust
was neat.

Unfortunately, its implementations are difficult to use, it was never directly
supported by operating systems or major applications, and its crypto agility
makes it impossible to write minimal implementations.

I wrote and use Piknik for small files transfer (especially with the Visual
Studio extension), Encpipe for file encryption and Minisign to sign software.
What they have in common is that they are very simple to use, because they
only do one thing, with very little parameters to choose from.

The main reason for having written these in the first place was that PGP is
too complicated to use, not that it couldn't have done the job.

~~~
philips
Has there been any effort to integrate minisign into git?

~~~
jedisct1
None that I know of, but it's never too late :)

------
Whatitat90
The post is well-written and summarizes I think most major pain-points with
PGP.

Comparison of all these tools to GnuPG is valid and it clearly shows not only
implementation problems but design ones as well in gpg.

What I fear is future riddled with all these incompatible tools. Even if
they're written by brilliant engineers and cryptographers they are not
_standards_ (e.g. IETF standards). Why is that important? For example
rewriting libsignal from scratch (for example to publish it under permissive
licenses) can be problematic [0].

[0]:
[https://news.ycombinator.com/item?id=12056673](https://news.ycombinator.com/item?id=12056673)

------
danielrangel
My minisign implementation in rust compatible with signify and minisign keys
[https://crates.io/crates/rsign](https://crates.io/crates/rsign)

~~~
jedisct1
And based on your implementation:
[https://crates.io/search?q=rsign2](https://crates.io/search?q=rsign2)

------
hiq
Glad to see wormhole listed here, I hadn't seen it recommended by security
experts before. Is there also a similar consensus about Syncthing and whether
it is secure enough for long-term file-sharing?

------
acqq
PGP has issues, but for many use scenarios there is effectively no ready
alternative at the moment.

Until there is, whoever already uses or knows how to use GPG is still better
off using GPG than not using anything.

Signal is especially not a good replacement for anybody who doesn't want to
have "secure" communication connected to his (or any) phone number and to the
central server.

The major issue with GPG is that in some (many?) cases a user could believe to
be more protected by using it than the user is. But the same can be said for
other technologies.

And the article rightly notes that the GPG defaults are often bad.

The right question to ask first is always:

[https://www.usenix.org/system/files/1401_08-12_mickens.pdf](https://www.usenix.org/system/files/1401_08-12_mickens.pdf)

Are you "dealing with Mossad or not-Mossad"? (Also worth noting is that
somehow Edward Snowden managed to "deal with" NSA and still remain out of
prison. At least he knew from the start the answer to the question.)

Still, anybody who wants to replace PGP in some PGP use-case should provide a
really good alternative for that use-case.

As of right now, there isn't any better for even such a simple need as
encrypting a file. Let's discuss it once we have that one, at least. And even
then, we'll need to be able to open our old files, meaning we'll still need
GPG for that.

------
viraptor
Another use case I don't know a replacement for is offline team+deployment
secrets. Requirements:

\- you need team members to read/write the secrets

\- you need the deployment service to read the secrets

Without using an online system managing the secrets via ACLs + auth, I don't
know how to replace PGP here.

~~~
lvh
what's wrong with an online system managing the secrets? KMS is great, and
makes it easy to separate decrypt from encrypt permissions.

(KMS is not the only option! I'm just trying to eke out why you think that's
valuable. For example, I think age, mentioned in the blog post, is a direct
replacement?)

~~~
viraptor
It has to be online. And reliable. And you can run into rate-limiting. And you
have to be online. And services using it need extra network configuration to
allow access. And if you can't narrow it down to a single ip/block you have a
service with full network access just to reach out to a KMS.

~~~
lvh
KMS historical downtime is pretty great, rate limits have been bumped quite a
bit to the point where I seriously doubt you're hitting them for secrets
management, I'm not sure you can do a lot of useful things with most secrets
while you're offline, KMS has a VPC endpoint and an Internet endpoint, so you
can do both variants of the tight network scoping you want.

(And, again, age once that's around :-))

------
w8rbt
Stop parroting these criticisms of OpenPGP without offering concrete, working
replacements that are widely adopted and have open standards.

Some kid recently tried to have OpenPGP support deprecated from Golang's
crypto-x package. And that's fine, but do not pull stunts like this without
offering a concrete, working and widely adopted replacement. Otherwise, they
are just that, publicity stunts with a lot of sound and fury but no solution.
That's not helpful to anyone.

A more mature thing to do would be to suggest deprecation in 3 to 5 years and
offer a plan of how to get there with other specific tools (some of which do
not exist today).

~~~
lvh
I was going to say something about how the article does mention several
alternatives, some of which far more widely deployed than OpenPGP.

But first: hold up. "Some kid"? You mean Filippo Valsorda? Google's Go Crypto
person? The same person who is writing the replacement for that one use case?

------
Anonymous4C54D6
Hi Thomas et al.! Good write-up and with several software suggestions that I
didn't know. Excellent! I think one thing you are missing is an "alternative"
for the identity problem. I somewhat agree that all long-term keys are a
problem but how do we build an identity out of a bunch of keys for different
systems, covering privacy concerns, with some sort of key transparency to
detect attacks, ... I think this would be a very interesting post from you
guys that I would love to read. ;)

------
verytrivial
I read these advice columns like "You should stop using hand saws because we
now have electric saws which are better in every way that I care about."
Great! You use them then. I'll keep using crufty old hand saws wherever I
want, you use and proselytize your electric saws and we can get on with our
lives. I have my own networks and threat models and my own evaluation
functions for these. Hand saws are pretty good.

~~~
tptacek
If your threat models have you using PGP, your threat models are badly
engineered.

~~~
verytrivial
That's pithy. I have used PGP sign (via an air gap) release tarballs on a
public server for clients that have individually verified my org's public key.
It made sense in this context and everyone already had the tools. My point is
we have our own contexts.

~~~
tptacek
If you used signify/minisign to do the same thing, your workflow would be
simpler, your keys shorter, and your entire stack more secure. Since clients
are individually verifying your key, none of PGP's identity goo is even
ostensibly winning you anything. Your context isn't the issue.

------
foolfoolz
i work with a manufacturer that’s a multi billion dollar behemoth and they
move at the slowest possible pace. every decision takes weeks, a hundred
emails, 20 phone calls, and 10 pdfs. we needed to add encryption to data we
exchanged. they said PGP and gave me a pgp key. i encrypted a test file and
gave my key back. within 20 mins we had an answer and moved on. this easiest
part of anything we have ever integrated with them

------
jmspring
Long story short - signed / encrypted emails are hard. SMIME doesn’t really
exist any more. Sending secure email is hard.

------
tebruno99
So far there has been a lot of hate on Hacker News about PGP. I'm sure most of
it is true, maybe we shouldn't use PGP. However, every single one of these
that offers suggestions cops out at end about encrypted files leave people
with.. PGP.

------
ajsnigrutin
But.. it's the only thing we have. Until some "pgp alternative" for signing
and encrypting emails comes along, and is adopted by "most" email clients,
it's the best thing we've got, even if it's "bad".

------
swalladge
Something I'm curious about - if GPG uses such old/not-recommended encryption
standards, is it still secure in the sense that if I gpg encryption something
and post it online, a three letter agency will be still unable to decrypt it?

~~~
lvh
There are two ways that breaks:

\- your key won’t be private forever but future compromise does mean past
disclosure

\- on long enough timescales if said TLAs can mount offline attacks against
it.

So, maybe? But it’s definitely the safest way to do it, most of GPGs problems
are unforced interaction errors.

------
dewyatt
> Every well-known bad cryptosystem eventually sprouts an RFC extension that
> supports curves or AEAD, so that its proponents can claim on message boards
> that they support modern cryptography.

I'm being attacked! :P

------
0xCMP
They mention encrypted volumes for offline backups and storing files which
must be encrypted. For cross platform I'm guessing VeraCrypt is the
recommended software now right?

------
chmike
So, how I sign git commits if I don't want to use PGP (GPG) ?

------
mongol
The pass password manager uses PGP, what would be a better design?

~~~
tptacek
Pass is an interesting case, because of how it's implemented. The easy,
obvious answer would be "a version of pass that uses libsodium (or Jason's own
crypto library) instead of pgp", but there's no command line for those tools,
and the only other command line widely available for cryptography is
OpenSSL's, which is horrible.

------
techslave
at first i thought, oh boy a rant from someone that can’t see past a pretty
GUI ... but actually he gets it. well worth your time to read.

------
summitto
Until a better solution is brought forward, my team implemented a PGP packet
library to make everyone's lives a little bit easier:
[https://github.com/summitto/pgp-packet-
library](https://github.com/summitto/pgp-packet-library)

Using our library you can generate PGP keys using any key derivation mechanism
for a large variety of key types! When using it right, this will greatly
improve how you can generate and back up your keys!

~~~
lvh
Does this improve on gpg2 —list-packets for practical debugging/auditing of
extant GPG setups, or is just useful for people who want to do alchemy on top
of the OpenPGP packet format?

~~~
summitto
It just parses the packets with a relatively easy API, for those which want to
do alchemy or which want to build tools for practical debugging/auditing
purposes in C++ instead of using shell commands.

------
thepangolino
PGP has one big problem:

Lack of a proper email infrastructure.

And by "email infrastructure", I mean proper support by most email clients
contact apps.

The most basic use case seem to have never been addressed. You receive an
email with a public key attached. Clicking on it should automatically open
your contact app and ask if you want to add it to your contact's details. It
should also be synchronizable with cardDAV or any other protocol of your
choosing.

------
tzs
While waiting for "age" to get written, can I use libsodium for file
encryption?

~~~
jedisct1
[https://download.libsodium.org/doc/secret-
key_cryptography/s...](https://download.libsodium.org/doc/secret-
key_cryptography/secretstream)

Battle-tested by ransomware already (sigh).

------
sparkling
So what should we use for public/private asymmetric encryption then?

------
CloudBuddy
Use ccrypt instead. It is very reliable. [https://github.com/Scott-
Kaplan/Client-Side-Encrypted-Backup...](https://github.com/Scott-
Kaplan/Client-Side-Encrypted-Backups)

------
eudora
Pretty shocking, thanks for such a detailed analysis

~~~
lucb1e
It's a large number of minor points. Nothing shocking, no huge issues, and of
course nothing we didn't already know. The crypto is good, if you manage it
well it stands up to the NSA as far as we know... Sure, it has flaws that make
it hard to use in general, and hard to use securely (no long term keys, for
example, would make me less paranoid about my private key), but it's still
fine despite having huge backwards compatibility.

The author is overly dramatic about it in order to make a point, to hopefully
get people looking for alternatives, so that a good one might take it from pgp
in the future (and continues to suggest whatsapp and signal, like, really?
That's your replacement for pgp?).

~~~
pvg
_The crypto is good_

It's not. This is detailed in the piece. What do you think it gets wrong?

 _That 's your replacement for pgp?_

One of the key points is that by now we know PGP is a bad idea _conceptually_.
There can't be a replacement for PGP. This is a bit like asking what what's to
replace mummification now that we know it doesn't really grant access to the
afterlife.

------
giomasce
As usual, all articles of this OpenPGP-is-bad kind keep failing acknowledging
OpenPGP's most important feature: it has a way (clumsy as much as you wish,
but existing) to attach identities to keys, and to verify them. I have a
rather well connected OpenPGP key, and that means that anyone can verify the
signed emails claiming to be from me are actually from me, even if we never
met. Of course you can mention XKCD and people saying they will never check a
signature, but that's their problem, not mine. If do not bother to check your
keys, any encrypting/signing system is untrustworthy. If you have a lot of
keys, each for any of your crypto applications, and no way to
cryptographically tie them to an identity, you will eventually mess them up,
especially if they have to be deployed on more than one machine.

I am perfectly fine with saying that GnuPG uses old algorithms, or that
different applications should use different keys, algorithms or techniques.
But, please, when designing such systems keep in mind that you want to check
where your keys come from and which identity they are attached to. And TTBOMK
only OpenPGP is currently able to do that. To me it would be great if all
crypto applications done in the right way would have a way to tie their keys
to the OpenPGP web of trust, in the same way Monkeysphere tried to do for SSL
and SSH keys.

------
btilly
And as for how PGP gets used in practice,
[https://xkcd.com/1181/](https://xkcd.com/1181/) did a good job of
demonstrating how useless that is.

Seriously, I'm a developer. I have never once felt motivated to verify a PGP
signature. Of anything.

------
spullara
Identity is an unsolved problem. Even outside of digital use cases.

------
classics2
Poorly thought out and argued.

------
roamingnomadic
Is this blog post satire? or an ad of sorts for some vaporware?

The talking alts either use PGP or a botnet. (signal uses PGP with a CA type
of thing, so much for "stop using pgp") and whatsapp is owned by facebook.

tarsnap as I understand requires that I lock in to a service to secure my
backups. F- that. Someone already talked about wormhole.

And how is essentially forking pgp with 'age' really going to solve things?
Wow thanks another forked app! :^)

It would be easier to just make a wrapper for gnupg that sets the settings for
everything the author is talking about. (well most of the things the user is
talking about)

Wouldn't it be easier to just inform maintainers of the package to change the
default standards of packages like gnupg? Has the author even attempted to
change some of these things?

Don't get me wrong, I get where the author is coming from. Uinx philosophy
should be followed... but certain systems can not be compartmentalized they
have to unfortunately interact with other another.

If you for example encrypt data without signing it, how would you know that
someone isn't trying to poison ciphertext to extract data leakage or worse
yet, they already found a way to decrypt your data and manipulating sensitive
data?

An encryption program by DESIGN should also have a method to sign data.

~~~
lvh
> (signal uses PGP with a CA type of thing, so much for "stop using pgp")

I legitimately have no idea what this means.

> And how is essentially forking pgp with 'age' really going to solve things?
> Wow thanks another forked app! :^)

A big part of the criticism we've gotten when we tell people "PGP bad" is that
we're not providing alternatives. age is one of those alternatives, for one of
those use cases.

> It would be easier to just make a wrapper for gnupg that sets the settings
> for everything the author is talking about. (well most of the things the
> user is talking about) > Wouldn't it be easier to just inform maintainers of
> the package to change the default standards of packages like gnupg? Has the
> author even attempted to change some of these things?

As we mentioned repeatedly in the blog post: no, the PGP format is
fundamentally broken, it is not a matter of "just fixing it".

> If you for example encrypt data without signing it, how would you know that
> someone isn't trying to poison ciphertext to extract data leakage or worse
> yet, they already found a way to decrypt your data and manipulating
> sensitive data?

I think you're making an argument against unauthenticated encryption here.
That's true! You should not have unauthenticated encryption, the way PGP makes
it easy for you to have. age is not unauthenticated encryption, so the
criticism does not apply.

~~~
roamingnomadic
Signal uses the same public key/private key cryptography. Hopefully that makes
more sense?

In any case, after reading the google doc more carefully, I see the idea isn't
to be against the whole pub/private key authentication its just a proposal of
how pgp works.

>age is not unauthenticated encryption, so the criticism does not apply.

yeah, I see. its pretty good actually.

~~~
tptacek
Signal does not use "the same public key/private key cryptography", nor does
it use a CA, or anything like a CA.

------
interfixus
> _If you’d like empirical data of your own to back this up, here’s an
> experiment you can run: find an immigration lawyer and talk them through the
> process of getting Signal working on their phone. You probably don’t
> suddenly smell burning toast_

Well, currently extricating myself from the Signal mess, I really _am_
expecting my smoke alarm to go off any minute.

On intallation a couple of years back, the Signal app desparately wanted to
curate my sms traffic, but forgot to inform me it would be holding my message
history hostage. Forgot to inform me it would kill my instance, should I ever
have the audacity to try setting up on a second phone unit. Forgot to inform
me that yes, there is a desktop client, but it is useless Electron crap.
Forgot to inform me it would be livestreaming my usage to everyone on my
contact list - when I installed, when I reinstalled or changed devices, or
when I mistook an ambigous list-feature for a personal book-keeping thing. The
last item didn't happen to me, but to an acquaintance who thus had a somewhat
embarrassing list of contact spilled out into the open. Not to mention the
whole phone number based ID disaster, and the lack of any web interface.
Sorry, but I'm out.

Fully aware of serious concerns about the crypto and the privacy, but for UI,
consistently well designed client apps, data export, and lack of nasty
surprises, I have seen nothing to rival Telegram. Which may help explain why
that seems to be where everyone is heading.

