Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] the 14th reason not to start using PGP is out!

carlo von lynX lynX at
Wed Nov 20 19:30:34 PST 2013

I know you've all been waiting for some more criticism about PGP. Well,
since I've been forced into using it I bumped into a major security failure:

   These days mail tools are too complicated. Here come enigmail
   that is in charge of encrypting mails before they leave Thunderbird.
   But wait, didn't Thunderbird just store a draft? Yes, and since I
   happen to have IMAP configured it stored the draft to my server. Did it
   bother that I had checked the flag that I intend to encrypt the mail?
   No, the draft is on the server in the clear. I look around and find out
   that [64]Claws has been having the same bug. I'm not surprised, after
   all it's the most natural way of doing things. One person implements
   IMAP, another implements PGP support, and they never bump into each
   other and realise that the default behaviour of a mail agent that
   supports both is to do what it should in no way ever do: send the
   unencrypted mail to the server. This makes the entire effort to use PGP
   useless. I looked around for warnings, but even the [65]best manuals
   for [66]doing PGP correctly are aware of a lot of problems, but not
   this one. I am only on day three of really using PGP, and I already
   discovered a security flaw that no-one has talked about much ever
   before. Is this normal? I have Thunderbird 17.0.8 and you?
   I recommend you to turn off saving mail drafts to the server.


I also recently had noticed that keyserver lookups are in cleartext by
default, which is utter madness, but that at least is being fixed and
there is good info on how to do so in [65]. Still, I wasn't expecting
that behaviour and thus exposed one of my social contacts when I did
this. If enigmail properly respected proxy settings, then the request
would have gone through Tor, but it just ignored them and went out to
fetch my contact's public key over my regular public IP. If I wasn't
monitoring my unfiltered traffic, I wouldn't even have found out.
And you call this software solid and properly peer reviewed? Srsly?

While I'm at it, let me respond to some comments that I didn't reply to
at the last round:

On Tue, Oct 15, 2013 at 04:26:34PM -0400, Ali-Reza Anghaie wrote:
> > The current policy of recommending PGP over more advanced tools is
> > probably causing damage to our end-users.
> The current policy of recommending tools that don't readily replace
> PGP ~in the way end-users user it today~ is causing more damage IMO.

Excuse me, Pond has some oddly aligned buttons but the service it offers
is way more advanced than SMTP. If you really think you don't want to
trust a new cryptographic tool - and don't have the money to finance a
review - then embed PGP encrypted messages into it. Still, the number
of failures you cannot possibly experience with Pond is so high that
it is a much safer tool than the above mentioned Enigmail.

Funny.. IMAP works so well, I can even see my unencrypted draft on a
different mail agent on a different computer...  :-D

And Pond is just an example. I could as well mention PGP over RetroShare
(although it already does PGP itself) with or without Tor wrapper.
Or what about Susimail and Liberte Cables? So many alternatives to SMTP!

> That's what I mean - ~you~ aren't pointing people at Snake Oil. You're
> just delivering a message of impending doom without giving them a
> flyer on where to go next that also fits where they ~can~ go
> (supported, COTS, or whatever).

Here's a flyer.. at I've been making a
comparison of the tools that are being developed. The number of problems
with e-mail are so big that I believe even not fully reviewed software is
a lesser damage - but as always you are welcome to go bullet proof by
combining the new technologies with older proven ones.

> In essence I'm saying it's dangerous to make such proclamations -
> however valid in ~our~ community - to the wide-open spaces of the
> Internet when "we" also aren't ready at-hand to provide solutions.

The document gave/gives indications on how to interpret it, including
the opening phrase that said that PGP is better than nothing.

> >> 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.
> No it's not - it's saying the car isn't responsible for the red light
> camera. It's important to break these things out in domains for which
> they (in this case PGP) was designed.

If you want me to say PGP isn't so bad. Okay, here I say it: PGP isn't
so bad. It's actually rather cool. Only few problems like non-repudiability
are inherent to PGP itself. Most of the problems are caused by SMTP, IMAP
and the like. How does this make anyone feel better?

> > 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.
> That's not what you did though - you say that now but there was a
> broad "viral" proclamation.

To start a debate, and looks like I was successful at that.
The "PGP" page is about the problems with e-mail and PGP.
The "comparison" page is about the new tools, and that one warns
upfront that all of the mentioned tools deserve a proper review.

On 10/15/2013 08:49 PM, Tempest wrote:
> but, again, pgp/gpg never pretended to provide "anonymity." if the

Oh no, "anonymity" means too many things. I'm saying precisely the
exposure of the social graph is a major problem because it's the
foundation on which totalitarian regimes have reigned successfully.
We can't postpone this issue just because we don't like the user
interface of Pond or RetroShare. Go fix it. Stop using a tool that
is not enough. If you're too much in love with your email client,
then write an IMAP/SMTP emulator for Pond.

> public perception of "secure" now includes anonymity, that is neither
> the fault of the tech nor a reason not to use it. rather, it's a reason

You are talking of the tech as if it was a person and I was insulting
it. Hey, I know that PGP was the reason why in 1993 we thought we the
citizen had won the crypto wars against them the governments. Here we
are twenty years later and we couldn't have been wronger. Can we please
replace the old bajonet now? You can still keep it shiny and clean and
hang it into a vitrine, but get yourself something that works.

> to learn tools that will help to anonymize a connection if that is what
> one desires.
>> 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.
> correct. people need to learn appropriate opsec based on the
> circumstances they are dealing with. it is more than possible for any

No, all they need is to start using a software that does all of that
BY DEFAULT and there is no way to do it wrong BY DESIGN.

> user to have a key associated only with an email address that has never
> been touched by anything but tor from their side. plenty of services
> exist that provide e-mail addresses for free without blocking tor. the
> question of how private those services may keep your communications is
> an entirely different issue, which is why the use of pgp/gpg is still a
> good idea.

This is all too complicated for people to even grasp let alone follow
and I bet half of the points in the 14 reasons still apply also to this set-up.
I leave it as an exercise to an interested reader to check.

>> 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.
> this would assume that servers never get discovered or compromised in

That's why neither Pond nor Susimail nor RetroShare nor TorChat nor Bitmessage
store any clear text data on any servers! (How many more tools do I have to list
to make you see that there is plenty of ferment in the scene of future
communication tools?)

> some way. a perfect real world example right now to refute the above
> notion is silkroad.

Actually it's not. It took them quite some effort to find silkroad and it
probably didn't even involve tracing Tor - at least there is no proof of
that. I think any federated social web software is a better example of
how servers get you compromised because of

> any person who used pgp/gpg to encrypt their
> communications with each other via that service is likely in a much
> better place right now.

Unless they get at your private key. Modern communication systems avoid
risking the exposure of your identity: all the data going back and forth
is encrypted with ephemeral keys which are changing all the time. Briar
is an excellent example of that. Tor itself, too.

> just because a server appears to be fully
> secured within the tor network is no reason to abandon pgp/gpg
> encryption of private communications.

Why are we talking of servers that have all the messages in cleartext?
I never recommended that as a reasonable replacement for SMTP. Although
I agree that PGP on .onion sites is safer than over SMTP.

On 10/16/2013 12:47 AM, elijah wrote:
> It is, however, entirely possible to layer a very high degree of
> confidentially, integrity, authentication, and un-mappability onto email
> if we allow for opportunistic upgrades to enhanced protocols. For
> example, we should be able to achieve email with asynchronous forward
> secrecy that is also protected against meta-data analysis (even from a
> compromised provider), but it is going to take work (and money) to get
> there. Yes, in the long run, we should all just run pond [2], but in the
> long run we are all dead.
> [1]
> [2]

Well, there are at least some problems with the LEAP approach that we
discussed in the past and since it keeps coming back I put it onto its
own page at - also I doubt SMTP servers will
do a better job at onion routing than a suitably optimized tool like

And if we wait for the world to "upgrade" to LEAP we're all dead while
Pond is already out here and functional. I agree with Jacob that it's no
use on insisting with SMTP, especially since Facebook is slowly eroding
it anyway. It should rather be us replacing it, than Facebook.

More information about the liberationtech mailing list