
What's the matter with PGP? - silenteh
http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html
======
tptacek
At one point in this essay, Matt suggests that every successful end-to-end
encryption scheme has employed transparent (or "translucent") key management.
What he's referring to is the idea behind, say, OTR: two people can use it
without the key handshake required by PGP.

Matt is wrong about this. He's being victimized by a pernicious fallacy.

It certainly appears that the most "successful" cryptosystems have transparent
keying. But that's belied by the fact that, with a very few exceptions (that
probably prove the rule), cryptosystems aren't directly attacked by most
adversaries... except the global adversary.

In the absence of routine attacks targeting cryptography, it's easy to believe
that systems that don't annoy their users with identity management are
superior to those that do. They do indeed have an advantage in deployability!
But they have no security advantage. We'll probably find out someday soon, as
more disclosures hit the press, that they were a serious liability.

There is a lot wrong with PGP! It is reasonable to want it to die. But PGP is
the only trustworthy mainstream cryptosystem we have; I mean, literally, I
think it might be the only one.

~~~
bdamm
PGP is only trustworthy if both parties treat key management with the utmost
severity, and if everyone in the conversation maintains the integrity of a
given thread (in the email case).

There are a precious few individuals for whom I have that level of trust in
their management of their private key. I could not even trust my wife to
manage a hardware key that I gave her, it would fall apart immediately; "I
cannot use this key on my chrome book? I cannot use this key on my Galaxy? I
cannot use this key on my iPad? Give me a soft key that I can use, or a cloud
service..."

Therefore, PGP is not mainstream. There is a large population of people doing
it incorrectly, and they must because they have no other real choice.

~~~
tptacek
Both of these statements can't possibly be true:

* PGP is only trustworthy if both parties treat key management with the utmost severity.

* Transparent key management systems that rely entirely on heuristics and click-through warnings are trustworthy.

~~~
matthewdgreen
Really they can both be true. They're just true for different constituencies.
The vast majority of users are not targeted by active attacks, nor should they
have reason to be. They may be hacked or subpoenaed after the fact.

~~~
antihero
I thought that "active" attacks is exactly what we were trying to guard
against?

------
Tharkun
Learning to drive a car is hard. You have to watch the road, coordinate hands
and feet, anticipate other drivers' moves and so on. No one bats an eye about
this, because "it's a skill you have to learn". If you don't play by the rules
of the road, you'll end up killing someone, or getting killed.

But for some reason (maybe because it's generally less life-threatening),
people seem to expect deeply complex subjects, like e-mail encryption and
identity management, to be easy. "Yeah, if you can just give me a fancy, easy-
to-use GUI with forward secrecy, that'd be great!" Sure, it'd be great. But
it's not going to happen. And that's not because PGP is broken -- of course,
it does have its weak points. It's because people are too lazy to bother to
learn.

What's the old addage? You can have quick, cheap and reliable. Pick two? Same
here. You can have secure, easy to use, and reliable. Pick two.

~~~
godDLL
I can't drive. Not for lack of trying.

I seemingly can't develop the the muscle memory of unintuitive (to me)
concepts like "clockwise is right" and "counter-clockwise is left", nor can I
get used to the way a gas pedal actuates non-linearly. These are just two
examples of a long list of problems that I have with the controls.

Then there is the utterly confusing signage.

I just can't do any of it, not without sweating like a pig. And I definitely
can't be doing all of it at the same time. That's just nuts.

Every time I pick up a PS3 controller I have to learn to use it again, which
depending on my withdrawal period can take anywhere from a couple of minutes
to like half an hour. The only reason I can touch-type is because I'm doing it
every day.

Please don't make the assumption that other's experience of the man-made world
around us is in any way similar to yours, that's just not true.

Oh, and I have had absolutely no problem figuring out PGP encryption usage.

~~~
Cederfjard
In what way are you contradicting Tharkun? I can't figure it out.

"Please don't make the assumption that other's experience of the man-made
world around us is in any way similar to yours, that's just not true." Where
did s/he? I'm genuinely stumped.

Learning to drive a car IS inherently hard (as in complex), just as "e-mail
encryption and identity management", and that is a fact. If you for some
reason are more or less adept than the average person at either of these
things, I don't see what difference that makes to the reality of the
situation. Like driverdan said, if you simply can't do something, you'll have
to find a workaround.

~~~
godDLL
What I said was to augment what he said.

But here's a true, I swear, you can probably check that it is, story just for
you:

I didn't know how the whole army thing works when my time came. Just wasn't
ever interested. Didn't know my sergeant from my brigadier.

The army took me seeing that I'm fit, for certain values of fit. Put me
through boot-camp. That's when I landed in military jail for the first time. I
could take everything that was going on in there only with a dose of humour,
but grinning 24/7 was apparently not acceptable behaviour. But that wasn't
what got me in jail.

There was one thing I could not take, absolutely. Still can't. There wasn't a
moment to myself, I couldn't ever get alone in there. I had to always be
accounted for, from their point of view; but from mine I couldn't find a place
or the time to take a short meditation. I don't know what I have, but I've
been getting through it all my life with meditation, and once that wasn't
available I was heavily depressed. I thought of suicide, I talked of suicide,
and that's basically all I ever talked or thought about. While grinning at
anything they had to say to me in return.

So I went home. Took my stuff and went out the gate.

Later came back and went to military jail for a sentence. Then for boot-camp
number two, as I didn't finish one.

But later when I did finish it on my second attempt, they didn't want me
anywhere near a base anymore. They wanted me out of base for most of the time.
They way to achieve this in the army is to make you a driver. This way you're
driving around, not being in the base, problem solved.

If you read my previous comment, you know what the problem with that approach
is. They didn't. So I explained, repeatedly. Any time they'd let me see an
officer that was in charge of that kind of thing, I'd explain that I can't
drive, won't ever be able to, and not even torture can "change my mind".

Either they have decided to test that last bit empirically, or just couldn't
wrap their heads around the idea of someone not being able to do something
that "any idiot could"; but long story short I've done 7 months of prison time
in three separate terms over the span of 1.5 years before they saw me as unfit
for service and let me go, and be as I am.

That is to say, you're not always in a position to find a workaround, if I may
refer to your closing sentence.

------
blueking
I don't agree. I use GPGtools on OSX with the openpgp smartcard and it works
flawlessly and is truly convenient. Furthermore I can use 4096 bit RSA keys.

One thing I have learned watching the crypto forums over the years is that
there are well calculated misinformation campaigns trying to dissuade people
from using secure methods. I see it again and again and the people on this
forum need to think carefully before swallowing this as sincere.

I would never never never trust a solution from Google or any large American
corporation. They have just been caught lying about prism (Google) and taking
bribes (RSA). These companies are now and always will be totally
untrustworthy.

~~~
nktr1
You talk bad about RSA and use RSA keys at the same time?

~~~
Cr8
[http://en.wikipedia.org/wiki/RSA_(cryptosystem)](http://en.wikipedia.org/wiki/RSA_\(cryptosystem\))

[http://en.wikipedia.org/wiki/RSA_Security](http://en.wikipedia.org/wiki/RSA_Security)

------
acqq
Why isn't RFC 1751

[http://www.ietf.org/rfc/rfc1751.txt](http://www.ietf.org/rfc/rfc1751.txt)

used to provide the fingerprints that are readable? Verifying would be much
more convenient than now.

"For example, the 128-bit key of:

    
    
             CCAC 2AED 5910 56BE 4F90 FD44 1C53 4766
    

would become

    
    
             RASH BUSH MILK LOOK BAD BRIM AVID GAFF BAIT ROT POD LOVE
    

Likewise, a user should be able to type in

    
    
             TROD MUTE TAIL WARM CHAR KONG HAAG CITY BORE O TEAL AWL
    

as a key, and the machine should make the translation to:

    
    
             EFF8 1F9B FBC6 5350 920C DD74 16DE 8009"

~~~
cpach
I haven't used the "original" PGP program for a very long time, but IIRC it
had the option to use RFC 1751 or a similar scheme. A quick web search finds
to options to use this scheme in GnuPG. Strange!

~~~
e12e
You're probably thinking of:
[https://en.wikipedia.org/wiki/PGP_word_list](https://en.wikipedia.org/wiki/PGP_word_list)

[edit: See also this thread: [http://lists.gnupg.org/pipermail/gnupg-
devel/2001-March/0170...](http://lists.gnupg.org/pipermail/gnupg-
devel/2001-March/017007.html)

I think they're missing (what I think was) the point of the list -- I seem to
recall this was meant for use over the phone, and the words were selected by
machine learning to all sound different. I've always thought this was a
massive case of over-engineering -- and also somewhat narrow-sighted. I mean
the list starts out with "Aardvark" of all things! ]

~~~
cpach
Yes, that's the list I was thinking of. The linked discussion was interesting.
Good find! Perhaps the GnuPG devs are right that hex finger prints are more
internationally viable than English words.

~~~
e12e
I've been thinking a lot about using words to stand in for numbers (eg:
fingerprints) -- and I think the idea is good. But i18n should be considered
-- and the PGP world list is probably the worst example I know of. The only
thing it has going for it, is that is already collected/created -- but seeing
as how it's not implemented by gpg -- that is kind of moot.

~~~
cpach
I can see why it would be hard to find one set of words that are easy to
pronounce/understand in every language and every culture. But perhaps that
isn’t necessary? I’m thinking that this feature needn’t be available in every
localized version of GnuPG. Or that there could be localized word lists for
various languages.

~~~
e12e
Maybe. I think sticking to something like the phonetic alphabet or "simple
English" would be ok.

------
rmoriz
In my opinion, mail crypto needs to become mainstream usable. E.g. even
trivial contents should be encrypted by default and this should be usable by
default. Currently, S/MIME does a better job than PGP.

While the CA-model seems to be broken in most X.509 use cases, like TLS/SSL,
where a duplicate certifcate can be used to do a man-in-the-middle-attack,
this does not really affect S/MIME, especially after both parties started a
"conversion". People that need to communicate "really" secure, should
therefore be able to ignore all "CA-Trust" and white-list certificates on a
per user basis (e.g. like PGP).

Ordinary communication still can by default fall-back to the existing CA-model
to keep it usable (but not secure).

Some steps:

1\. We need more love by the MUA-vendors, who mostly support S/MIME but it's
still a PITA to use. Google e.g. still does not support S/MIME on android, see
[https://code.google.com/p/android/issues/detail?id=34374](https://code.google.com/p/android/issues/detail?id=34374)

2\. We need CAs that are usable. StartSSL is nice and free, but it's not easy
to use. Lower the entry barrier for getting and renewing/recreation of
certificates

3\. (most important) Make it easy to manage local CA-trust. On each new
system, the user should be able to select a "trust no CA/whitelist only"
approach and then be responsible for trusting other parties. No vendor
(Microsoft, Apple, Google, Mozilla) should silently distribute and trust new
CAs without users consent.

~~~
beagle3
The "global CA" model is bust. How it was ever considered usable is beyond me,
but we now have more than a decade of experience seeing just how bad it is. It
is utterly, fundamentally broken and easily subverted by state actors.

For now, the only reasonably usable secure key exchange method seems to be
what WhisperSystems are doing on their phone app (safe against MITM if the
parties know each other, and very hard to MITM even if not - especially not
automatically).

~~~
aianus
What's wrong with blockchain based solutions like namecoin?

~~~
beagle3
If I understand correctly, namecoin is a distributed DNS replacement. Is there
a way it addresses impersonation (e.g. MITM?), if so, can you please point me
at documentation?

DNS does not address it, and even DNSSEC does not (if you can forge the
certificate, and you can mitm the traffic - which state actors are all capable
of - then it doesn't matter that you can't forge the DNS response itself).

~~~
aianus
You can place your own self-signed public key in your namecoin record. There
is no longer any need for certificate authorities which can be coerced into
forging certificates.

~~~
beagle3
Well, if this is properly supported by software using namecoin for DNS
resolution, then - yes, this may work. The proof of the pudding, however, will
arrive once it's eaten. I am not familiar with namecoin to point where the
potential problems are, but do note that the failure of CAs is not in the
cryptography but rather in the trust model. In modern cryptography, the
problems are almost always with the practice, not with the theory.

~~~
rakoo
> software using namecoin for DNS resolution

Actually, it should be the other way around: dnschain [0] bridges DNS
resolution and namecoin, so there's no need to modify existing software.

[0]
[https://github.com/okTurtles/dnschain](https://github.com/okTurtles/dnschain)

~~~
beagle3
Cool! wasn't aware of it.

------
graycat
> If the NSA is your adversary just forget about PGP.

Why? Last I heard, breaking PGP was equivalent to being able to factor large
integers into a product of prime numbers. So, NSA is able to do that, and no
one else can, no one in the public heard about it, no university research
mathematician published about it, NSA has mathematicians who figured out how
to do that but their major profs back in grad school don't know how, no one
got a Fields Medal for it, etc.? I don't believe that.

What's going on here?

He means I need a Faraday cage? Okay, tell the NSA I have one; put it in place
this afternoon.

He means the NSA has trained cockroaches that can wiggle into my hard drives
while I sleep and steal all my data? If so, then fine. I'll spray bug killer.

Otherwise, why should I believe that the NSA could crack my PGP encrypted
e-mail?

~~~
bascule
If the NSA can't attack the crypto (not saying they can, but maybe) they'll
attack endpoint. Systems like QUANTUMINSERT allow them to selectively MitM
your plaintext HTTP connections, directing your browser to load some asset
that exploits a browser vulnerability, and using that to install persistent
malware.

------
ef4
Yes, usability is the problem. But none of these proposed solutions manage to
actually solve the usability problem without throwing out the security.

We really _do_ need to let users manage trust, because trust is a rich
concept. And humans are actually really good at trust, because we've been
thriving and competing with each other in complex social situations for a long
time.

The trick is finding ways to recruit people's evolved trust behaviors into an
electronic context. That is, can we build meaningful webs of trust through
repeated social interactions, just like in real life?

So it's not the mail client vendors who are best positioned to solve the
problem, it's the social networks.

(Whether they _want_ to solve the problem is a separate question.)

------
junto
I'm using TextSecure on my Android phone as a Messaging replacement and it is
great. However it appears to me that the service is not decentralised in any
way. Is that assumption correct?

I like the email model such that anyone can install and run an email server.
I'd actively push friends, family and colleagues to use a decentralised email
replacement that was as easy to use and secure as TextSecure.

~~~
XorNot
I don't trust TextSecure. It's _too_ transparent. It is entirely unclear what
happens if it can't send an encrypted message. It's unclear where and how much
I'll be billed (important to those of us outside the US). And sans user
authentication, there's no real trust model there.

~~~
irv
Feel free to not trust it, but it does indicate whether the message to be send
will be encrypted or not: in the current version, a padlock will be locked or
unlocked on the send button. If you receive an unencrypted message from
another text secure user, it automatically detects the other party is using
text secure and offers to initiate key exchange.

The billing criticism is fair and warranted; currently if your sending over
SMS, the first message can only contain 60 chars due to protocol overhead, so
you often end up with short messages costing multiple SMS.

There is a way to verify keys (manually!) but no indication that you have
verified them.

------
Teodolfo
The user needs to control the encryption, not Google or Yahoo. Surely Google
is not proposing a system that prevents them from reading your email and
serving you ads? Until we have something that actually prevents Google and
Yahoo from getting the plaintext, none of the other problems matter that much.

The NSA isn't my concern, Google etc. are. I don't want to bother going to the
lengths necessary to secure myself from the NSA since that just isn't
practical. But it would be nice if google and its employees didn't have access
to the plaintext of my email. If I send an email to anyone using gmail and
they decrypt it in a way that lets google see my text when they reply, all of
my own security steps are worthless.

------
TeMPOraL
Just a random thought - maybe there is a way to nail hard the point that "you
cannot have security if you're lazy"? The society expects people to do driving
licenses before getting behind the wheel. Why not expect people to put some
amount of effort to be able to get mortgage or interact with court, etc.?
Sure, many people will screw this up, but maybe this will be enough to secure
majority.

</dream>

(confession: I myself am too lazy to use PGP)

~~~
Someone1234
Counter example: I'm not too lazy to use HTTPS.

Maybe if email encryption was more like HTTPS more people would use it? Just
transparent and easy.

~~~
TeMPOraL
> _Maybe if email encryption was more like HTTPS more people would use it?
> Just transparent and easy._

Sure, but the point of a lot of comments here seems to be that It Can't Be
Done.

~~~
marcosdumay
It certainly can be done.

It's just that lots of people think HTTPS security is not good enough. (And
you can include me on that set.)

------
nextw33k
PGP is about identity and privacy. We are not going to get that from Email.
Email isn't worth fixing. Its time to move on.

In the last few years we have seen IM and SMS merge into an almost seamless
experience. Surely we could engineer a UI that also copes with larger bodies
of text at the same time?

We need clients or servers that are multi-protocol. That way we can experiment
with new ways of communicating.

------
motters
Good article. However if your adversary is a three or four letter agency then
by all accounts it seems that PGP/GPG still does work. Snowden and Greenwald
used it, apparently successfully after some tuition.

The article also doesn't mention Bitmessage, which addresses a lot of the
concerns. Bitmessage isn't forward secret though.

------
gkop
Here is a good criticism of PGP from 1999 that explains why it isn't usable by
ordinary folks -
[http://www.cs.berkeley.edu/~tygar/papers/Why_Johnny_Cant_Enc...](http://www.cs.berkeley.edu/~tygar/papers/Why_Johnny_Cant_Encrypt/OReilly.pdf)

------
jolan
Here's a handy guide which addresses a couple of these problems:

[https://help.riseup.net/en/security/message-
security/openpgp...](https://help.riseup.net/en/security/message-
security/openpgp/best-practices)

------
lelf
Not mainstream ≠ suck.

Also, about “terrible mail client implementations”, — the problem is, to not
be terrible for many is to be built-in to GMail (and work transparently
there). The consequences of that are obvious I hope. So no, thanks.

------
ajb
This could perhaps be made easier to use if you had a UI like this: You phone
pops up a message saying: "Hey, I notice you seem to be in the same room with
Bob! We can increase security of Bob's messages to you my exchanging a
fingerprint. Do this now? (Yes/No/Woah, Bob isn't here!)

If you click yes, you then exchange fingerprints using eg QR codes, and the
authenticity of messages from Bob are _retrospecively checked_

Problem is, it's not obvious this can be done without compromising privacy of
location.

~~~
marcosdumay
> Problem is, it's not obvious this can be done without compromising privacy
> of location.

That's a problem for Free Software running on local machines!

------
zokier
> Adding forward secrecy to asynchronous offline email is a much bigger
> challenge, but fundamentally it's at least possible to some degree.

Is it really fundamentally possible? The author asserts this without really
backing it with anything. I can understand how OTR-like systems can work
between a static pair of clients, but it is not entirely clear if it is
possible at all to extend such scheme to work in scenarios where message
delivery is async and I might be using a set of clients/devices for messaging.

~~~
pbsd
Matt links to a paper on forward-secure public key encryption in the notes.
While this shows it is possible in principle, the actual procedure is pretty
awkward, and probably not usable in this current state.

------
exabrial
PGP needs to onboard themselves with Elliptic Curve Crypto... significantly
smaller makes them more distributable which solves a few of the problems
mentioned.

~~~
tptacek
Most systems should switch from simple multiplicative group crypto to elliptic
curve, but it's hard to make an argument that doing that would resolve any of
the problems Matt is referring to.

------
muyuu
These are largely problems with email, not PGP - which btw is not just by
email, in fact I almost never use it with email.

SMTP is not meant to be secure. You insist in communicating through an
insecure channel-protocol and making it secure as an afterthought, and it's
always going to be inconvenient or otherwise suck. I say PGP is pretty good at
what it does, and it's nice in that it doesn't promise what it doesn't do.

------
alaaibrahim
> Now let's ignore the fact that you've just leaked your key request to an
> untrusted server via HTTP. This is a public Key, so secrecy it's not needed
> here, also he is providing the Fingerprint on another location, so if there
> was a MITM attack, it should happen on both twitter (HTTPS) and pgp.mit.edu

~~~
mdavidn
I think Matthew Green's point was more that requesting a public key leaks your
intent to communicate with someone—the metadata, if you will—to an untrusted
third-party.

Of course, e-mail headers, including From and To, must necessarily transit as
cleartext, even when e-mail bodies are protected by PGP. The keyserver should
perhaps be the least of Matthew's concern.

~~~
e12e
So... gpg + mixmaster remailers + Tor for http?

------
perlgeek
Can forward secrecy even work for emails, where you don't have a bidirectional
communication channel? (Maybe the answer is "You have to build that
bidirectional communication channel", but that means such a system can't
simply use mail, it has to use mail plus X).

~~~
e12e
If we assume Alice and Bob use the keyserver network, and each have their own
"master" key-pair that is mutually trusted, they can rotate public sub-keys
quite frequently (you just need to search for any new keys before sending an
email -- this is of course another (not smtp) channel -- but who doesn't use
keyservers?).

------
warcode
keybase.io and the mailvelope browser plugin both do fine work in making PGP
simple to use.

It isn't about being NSA-proof, its about having the volume of "Enveloped"/PGP
encrypted emails be so high that it isn't possible to directly target
everyone.

------
skrowl
No perfect forward secrecy. If someone gets your PGP key, they get all of your
messages (past / present / future) and you might not even know your key was
compromised.

~~~
Sami_Lehtinen
Of course you can use forward secrecy (PFS) and ephemeral keys with
PGP/GPG/GnuPG. I've been doing that for ages. Any public / private key system
is able to do that. Simply generate new key pairs and send the new signed
public key when ever that's necessary. I've blogged about that several years
ago, when someone claimed that it can't be done. You can freely select if you
want to rotate keys on every message, daily or so.

~~~
skrowl
So you're just going to keep 1000 private keys around to decrypt your old
stuff?

------
based2
[http://www.theregister.co.uk/2014/08/14/pgp_viability/](http://www.theregister.co.uk/2014/08/14/pgp_viability/)

------
BillFranklin
I think [https://lavaboom.com/en/](https://lavaboom.com/en/) addresses most of
the issues mentioned. Just because pushing for privacy (an abstract idea,
difficult to measure the worth of - especially on the Internet) is hard
doesn't mean we shouldn't do it. Encryption is one of the fews things we can
rely on and we should be using it. PGP isn't a lost cause, we just need to
make it easy use - this includes automating (to some degree) the key exchange.
/I'm one of the founders of Lavaboom, happy to answer any questions/

------
eyeareque
I just hope that however google and yahoo implement PGP into their mail
offerings, they do it in a way that cannot be intercepted by governments/bad
guys.

~~~
nktr1
but they are not allowed to tell you if it can be intercepted...

~~~
eyeareque
exactly, which is why they'd need to build it in a way that cannot be
backdoored.

However, if the government comes to Yahoo/Google, and says: give us a
backdoor.. how can we be sure it doesn't happen?

------
colanderman
> _even modern elliptic curve implementations still produce surprisingly large
> keys._

> _Modern EC public keys are tiny._

Well, which is it?

------
aestetix
I'm kind of sad the author didn't touch on key signing at all. The trust
levels are basically meaningless. What does it mean to trust someone more than
someone else? If doing a request to get someone's key exposes your social
network, imagine what publicly signing someone's key does. Just some food for
thought :)

~~~
indeyets
trust levels used during signing represent quality of identity check. in
simple terms: if you checked ID of the person that is "sig3", if guy just
claims the name on internet than it's "sig1"

on the other hand, "owner trust" is a local concept which is not exported and
used solely for trust-path verification

------
zimbatm
> Except maybe not: if you happen to do this with GnuPG 2.0.18 -- one version
> off from the very latest GnuPG -- the client won't actually bother to check
> the fingerprint of the received key.

Even in it's long form, it's relatively easy to generate different keys that
have the same fingerprint.

~~~
croikle
I'm aware of simple brute-force attacks on short key IDs [0], which are just
the last 32 bits of the fingerprint (e.g. 438CF0E2). With significant effort,
one might be able to extend that to 64 bits.

I'd be much more surprised by a full fingerprint match. Wouldn't that imply a
SHA-1 collision?

[0] [http://www.asheesh.org/note/debian/short-key-ids-are-bad-
new...](http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html)

~~~
zimbatm
Yes I was referring to the 64bit long key ID. The full fingerprint is a SHA-1
and not vulnerable.

See [https://www.debian-
administration.org/users/dkg/weblog/105](https://www.debian-
administration.org/users/dkg/weblog/105)

------
uvTwitch
Yeah really, it's actually Pretty Good if you think about it.

------
pdkl95
Problem:

PGP is complicated (VERY complicated, to the average user), resulting in next
to zero adoption.

Suggestion:

Simplify the goals in a way that can be upgraded at at some later date.

I think we need a browser plugin (All browsers. Other non-browser tools too,
ideally, but the browser is important) that lets you securely _SIGN_ posts
locally in a style more or less like GPG's --clearsign option. Ideally, this
should _literally be_ \--clearsign for compatibility, with the plugin hiding
the "\---- BEGIN PGP SIGNED MESSAGE ----" headers/footers, though these
details are less important.

The key should be automagically generated, and stored locally in a secure way.
(Bonus points for leting you use the keyrings in ~/.gnupg/ as an advanced,
optional feature). The UI goal is to simply let people post things and click a
_sign this_ button next to a <textarea> or similar. Ideally, later on, this
could become sign-by-default.

On the other side, the browser plugin should notice signed blocks of text and
authenticate them. Pubkeys are saved locally (key pinning). What this provides
is 1) verification that posts are actually by the same author, and 2) it
proves that someone is the same author _cross-domain_ (or as different
accounts/usernames).

No attempt is made to tie the key to some external identity (though this would
be somewhat easy for to prove). The idea is to remove the authentication
problem (keyservers/pki) entirely. This can be man-in-the-middled, but the
MitM would have to be working 100% of the time or the change in key will be
noticed.

No attempt is made regarding encryption (hiding the message). This should also
greatly simplify the interface.

The goal here is to get people using proper (LOCAL STORE _ONLY_ )
public/private keys. The UI should be little more than a [sign this] button
that handles everything, and a <sig ok!> icon on the reading side. It should
be possible to get the average user to understand and use such a tool.

 _Later_ , when the idea of signing your posts has become more widespread and
_many people have a valid public /private key pair already in use_, other
features can be added back in. As those "2nd generation" tools have a large
pool of keys to draw from, it should be easier to start some variant of Web Of
Trust. Even if that never happens, getting signing widespread _is_ useful on
its own.

I realize this doesn't protect against a large number of well-known attacks,
and only offers mild protection against MitM. This is intentional, as the goal
is getting people to actually _use_ some minimal subset of PGP/GPG-like tools,
possibly as an educational exercise. The rest of the stuff can be addressed
later.

~~~
harlanji
I've designed an API for this and started working on it since I got a Yubikey
Neo in the past few weeks, if you or anyone is interested. I'm focusing on UX
specifically.

My design has a REST endpoint that runs locally, and a JS client/SDK then
connects to it on a known endpoint. My "MVP" version is to have the user
running an interface with the request queue in a separate tab, and the server
always at a fixed localhost:port endpoint. The client page would then issue a
REST request that hangs until the user responds to the request in the separate
tab.

This would conceivably work as a browser plugin as well since I'm planning to
write it in JS for Node--basically the server logic would instead live in the
plugin and the SDK would check for presence of the plugin before making a REST
call. IMO the advantage of making it a REST endpoint though, is protecting
private keys from whatever else might be going on in the browser
process(es)--based on my own worst-case on assumptions, unsure if it's
actually an issue with the plugin architectures.

I'm an aspiring interaction/UX designer so that is the aspect I am focusing
on, and my motivation is that I am personally starting to use GPG with a
Yubikey + offline master. So yea, collaborators hit me up, especially if
you're in SF.

------
pconf
This article fails my smell test. The adolescent vocabulary doesn't correlate
with the otherwise polished writing style and the technical merits fall far
short of the proposed remediations. It is therefore likely to have been funded
or otherwise inspired by the NSA in an attempt to smear PGP, still the most
effective cryptography available to the average person.

