[liberationtech] 13 reasons not to start using PGP

[carlo von lynX]

First of all let me thank everyone for feedback and tweets gone viral.  :)
I will answer some comments below but first I will introduce you to
the brand new THIRTEEN reasons not to start using PGP.

I added Gregory's critique on non-repudiation (8), Mike Perry's critique
on the Web of Trust (which could count for three points against PGP ;-))
(7) and I added a fundamental review of e-mail's dependency on DNS and
X.509 in a world where these things work better with DHT technology (11)
- at zero administration effort and almost zero cost - compared to the
stupid work it is to do mail and jabber administration.

And I am really curious about elijah giving me some argumentation
concerning the bootstrap fallacy (13), as it sort-of questions the
usefulness of the entire LEAP project.


On 10/11/2013 08:19 PM, Ali-Reza Anghaie wrote:
> I love the detail put into this but I think it's a poorly delivered
> message for multiple reasons:
> 
> 1) It puts an over-abundance of faith in toolsets in opening and
> closing "You have to get used to learning new software frequently."
> Realistically if this was a toolsets problem then EFF and EPIC
> wouldn't exist - it's not. It's a problem of State that can only be
> fought through OPSEC, policy, and risk management. Since it's not
> entirely reasonable to have end-users living the spook lifesystem then
> it leaves ~policy~ as the best out for end-users with tools (like PGP)
> being the defensive linemen.

Currently it is a major toolset problem.
That doesn't preclude there are other problems, too.

> 2) Combined with (1) - then providing no immediate alternative - it
> creates the environment in which snake oil fills the gaps. Then we're
> back out fighting the snakeoil because we were too busy eating our
> young (or old in this case) to pay attention to the collateral damage
> to our end-users.

I am not recommending any snake oil because I am too competent
for that. What I am recommending is source codes that give me
a good impression and deserve a serious review.

And I'm also saying that yet another PGP user interface is useless.

The current policy of recommending PGP over more advanced tools is
probably causing damage to our end-users.

> 3) It groups multiple problem sets into the responsibilty domain of
> PGP - when it/they don't have to be, perhaps even undesirable to be so
> (from both technical and sociological viewpoints).

It's like saying if the mirror in your car is broken it has
nothing to do with driving, because the mirror isn't doing the
driving.

> So in terms of broad proclamations I think it's prudent to keep those
> at a policy level - and the rest behind transparent but loosely narrow
> doors until the collective geekdom "we" can get traction on better
> alternatives. -Ali

PGP/mail is so broken that there is a risk that even if there
are bugs in the new software programs they may cause less damage
as PGP. We're at a point that we can't safely argue which of the
two options are safer, and each user would have to take a chance
for himself. That's why I urge you to review the alternatives so
we CAN make reasonable recommendations like we used to do.


On 10/11/2013 07:24 PM, Tempest wrote:
> i am often a bit confused as to why people take issue with the fact that
> gpg/pgp isn't anonymous. i don't recall the technology ever being
> proposed as such. rather, effort was made to have mechanisms to verify

People expect PGP to be "secure" without having such a clear idea
of what they mean by "secure." Suddenly, times have changed.
This summer times have changed and nothing is as it was.
Now we know just being able to encrypt and sign is not enough
for most situations in life. It's no longer "secure."

> the identity of a sender. however, if one creates an identity and
> keypair that as only been used over tor, what's the problem? creating
> and maintaining anonymity is an entirely different subject that gpg/pgp
> was not created to address.

You can't just use it over Tor, you also need a mail server willing
to give you an account anonymously and then you need all your
communication partners to do all of that configuration and
finally you need to configure PGP so it won't expose who you are
sending to.


On Fri, Oct 11, 2013 at 10:52:44AM -0700, Gregory Maxwell wrote:
> You add encryption via PGP because you know you need encryption in
> order to be secure against your threat model.  But without it being
> very obvious PGP has written a long term identity fingerprint encoded
> in the opaque base64 data which distinguishes your messages by
> recipients.
> 
> This long term identity key can _increase_ your vulnerability to
> traffic analysis over using nothing at all. It does so invisibly to
> many users. It may be a very bad thing for your threat model.

Ouch.

> I think communications security tools ought to avoid increasing
> vulnerability to any common threats to the greatest extent that they
> can, and when they must compromise they should make it obvious.
> 
> Both for non-repudiation and resistance to traffic analysis PGP
> dramatically reduces user security and does so in a way which is not
> obvious to any except the most advanced users. Both of these could be
> fixed with basically no user impact: Make hidden-recipient the default
> and allow optional clear-text recipient list on ascii armored output;
> add an "authentication" mode which is used by default instead of
> signing for encrypted messages that uses ring signatures (and don't
> allow unauthenticated encryption, geesh).

Not clear to me how an "authentication" mode would work...


On 10/11/2013 09:10 PM, Tempest wrote:
> a fair point. but one could significantly address this issue by hosting
> the public key on a tor hidden service. that would greater ensure that,
> in order to get your key, they would be using a system that protects
> against such threats. hardly an "easy" solution. but it can be solved
> with a little extra planning.

I was just thinking to answer that you could leave out PGP entirely
in this scenario, but...

On 10/11/2013 09:24 PM, Gregory Maxwell wrote:
> Of course, if you can do this and the HS is secure, then you can just
> dispense with the PGP altogether.

Gregory said just that  ;)

> You can work around the limitations I've pointed to here... You
> messages via hidden services without pgp at all.. or you can create
> per-recipient symmetric keys which you clearsign then encrypt with
> hidden-recipent to each person you want to talk to, then symmetrically
> encrypt your actual messages, and discard once a conversation is done.
> 
> But no one does, because it's hard, and some of PGP's downsides are subtle.

Pond, TorChat and various other Tor apps do this kind of thing
in various styles. I also have a prototype of a torifyied PSYC
server so that it serves as a distributed chat system for Tor.
Anything is better than PGP.


On 10/11/2013 06:34 PM, Michael Rogers wrote:
> On 11/10/13 01:14, carlo von lynX wrote:
>>> No one anywhere has solved the problem of asynchronous,
>>> forward-secret group cryptography.
> 
>> I think you have to be a bit opportunistic about it. Briar does it
>> somehow, if I understood correctly.
> 
> Yes and no. I think Elijah's referring to the problem of encrypting a
> message to a group of recipients, so that any recipient can decrypt it
> up until a certain time, and nobody can decrypt it after that. We
> haven't solved that problem, but we do have a different solution for
> asynchronous forward-secret group communication.
> 
> No crypto innovation is involved, it's just a matter of group members
> disseminating the message over forward-secret pairwise links. I think
> Retroshare might do the same... but who knows? ;)

Yes, AFAIU Retroshare does it the same way. GNUnet will probably do
similar in the first iteration, plus we make the channel source
sign the messages so you can't modify them in transit. This allows
us to later add rekeying at the channel source. To clarify: the
channel source is not the author of the message but the host of the
channel.