PGP: There’s Life in the Old Dog Yet

https://blog.whiteout.io/2015/02/25/pgp-theres-life-in-the-old-dog-yet/

by onli • 11 years ago

83 77 11 years ago

blog.whiteout.io

zvrba• 11 years ago

Is anybody working on making identity-based encryption mainstream?

onli• 11 years ago

Are you thinking of something like https://keybase.io/?

bradleyjg• 11 years ago

IBE requires a trusted third parties to issue private keys to users. That's essentially the lavabit model with slicker math.

cpks• 11 years ago

Gosh. I like the concept, but the web site really needs more information and better design -- starting with whether this is a free or paid service.

felixhammerl6• 11 years ago

website update is coming soon :)

wuschel• 11 years ago

Quoting Dan Geer: "Convenience, freedom, security - choose two."

Solid cryptography concepts were never easy to implement and use.

My main problem lies not with the Gnu/PG or PGP software implementations, but with the actual platforms. Do I trust my iPhone/Android/public internet cafe computer/the family computer? Is it compromised? What about your computer manufacturer? Lenovo, perhaps? Or Apple?

The problem of information safety does go far beyond software. Neglecting this is not an option.

There is certainly life in the old dog called pgp, but I am yet to be convinced of a mass market software concept that allows me to have the same level of confidence in its security as the open source packages I have installed on my offline computer.

"The paranoid will survive."

tomjen34• 11 years ago

I probably shouldn't go around and disagree with quotes from people I have never heard about, but there is no law that means encryption has to be ackward, user-unfriendly or badly designed.

Retric2• 11 years ago

Can you name a single counterexample?

HTTPS: You can give up freedom and some security for convenience of 3rd party registrars! You can roll your own which is less convenient and likely less secure… Not really sure of the 3rd option here.

worklogin• 11 years ago

More like a theorem. And Dan Geer is totally worth reading.

http://geer.tinho.net/geer.rsa.28ii14.txt

https://encrypted.google.com/search?hl=en&q=site%3Ahttp%3A%2...

Dylan16807• 11 years ago

Choose two? How do I pick security and convenience without freedom? I can't think of any way giving up freedom makes those easier. Blind trust can make me ignore security problems, but I can have blind trust and freedom, or lack of freedom without blind trust.

I feel like "security or convenience" is a better representation of the choice, even if it's not as cute. Freedom is off to the side.

zby2• 11 years ago

Addressing the Moxie Marlinspike post - PGP being flexible and comprehensive is not the problem. The implementations/libraries (including GPG) being a fossil from last century are.

From my own experience I can say that the libraries are not well designed - they couple things together (like key management and decryption) and make some things hard to do even if they are conceptually simple (like checking a signature without first building a key-ring data structure with all keys from a file).

Progress comes from many experiments, going in all kinds of directions in UI design, infrastructure building etc. You need a comprehensive fundations to base on these experiments on.

eukaryotia• 11 years ago

You need a comprehensive fundations to base on these experiments on.

The problem is that people build this huge, powerful libraries, but nobody seems to write the "limiting" libraries that take a subset of the powerful base library and create an easy to use experience from the user.

I suppose this largely stems from "implicit knowledge": People who can write cryptography apps likely know enough crypto that they can't themselves identify usability problems.

zby2• 11 years ago

Libraries are more powerful if they are decoupled. For example I wanted to build a website that would let you check message signature against public keyservers. This sounds trivial - but unfortunately the libraries that I've reviewed don't provide a 'check_sig( message, public_key)' function - but only a 'key_ring.check_sig( message )' function. This complicated the matter a lot - because I would have to download the public key and save it into a temp file and then build a key_ring out of that file (with some other complications that I don't remember right now). Enough to discourage me.

Huge does not mean powerful when it is hard to mix and match (and limit) the functionality.

felixhammerl6• 11 years ago

you are mixing two problems:

1) libraries are often too complex for the avg dev: well, crypto is complex and there is rarely a one-size-fits-all solution. however, there are high level APIs that address your issues in openpgp.js (https://github.com/openpgpjs/openpgpjs). problem is that a lot of people try to roll their own crypto if the library does not offer those high level #box() and #unbox() functions. and THAT is a real problem down the road.

2) lack of empathy is really a big problem, which I've articulated here: https://blog.whiteout.io/2015/01/29/why-alice-has-a-problem-...

malgorithms4• 11 years ago

Since Keybase inevitably comes up in these PGP conversations, 2 things in advance:

1. I've really been very slow in letting people into Keybase. The wait time is still 6 months (last night I was letting in people who asked back in August.) But now that we've added HackerNews key proofs, I'll let people in today who notice this post who have more than 1 karma and write "I'm HN: {theirusername}" in the request form.

2. We're not just about PGP keys. It looks that way now, and our first goal was to help solve the very on-the-record type things developers do. Which mostly requires PGP - and PGP is very good at. Signing code and commits, releasing software, etc. But sometime soon each of your Keybase devices will have a device-specific Nacl key, for example. And the process for provisioning devices is something we're taking very seriously - we'll soon have a big blog post about how public sibling key announcements will work. Here's the foreshadowing: with a Keybase account, very soon you'll be able to start with something as simple as a Twitter or HN username, and do some very cool, secure things with files and messages.

[EDIT] We are hiring. There's no specific job page because we've mostly been reaching out to people quietly, but we want help building: the Keybase client (Go), iOS and OSX GUIS (Obj-C), and the site (front end development and back end (Node)). Please reach out to me (chris@keybase) if you like the idea of working on usable security software. We are currently distributed in NYC, SF, and CHI, and ideally you'd work with us in one of these offices.

peatmoss• 11 years ago

Hmm... I never knew about you guys. I think I may need to do this. I've been meaning to get rolling again with GPG, in part because I want to move to `pass` for password management. Might need to spend some time today getting my ducks in a row.

malgorithms4• 11 years ago

Cool, just keep in mind Keybase isn't an email client. So if your goal is encrypted email communications, you'll still need to pick a client for that. Whiteout/Thunderbird w Enigmail/Mail.app w/GPG Tools are all apps to look at for your desktop.

Keybase right now is basically just a directory. It's a different model for making sure you get the right key for the right person. As diafygi pointed out, the traditional PGP keyserver model is busted. There's no canonical ordering of key announcements and revocations, and the gossip protocol is messy. Solving this based on social accounts is our top priority. Every proof or revocation you do on Keybase is put into a chain for you, and in turn that chain is attached to our merkle tree and written to the bitcoin block chain. We want to prove everyone in the world is getting the same answer from Keybase, everything is ordered, and that we're not omitting anything.

What you then do with those keys is up to you.

urda• 11 years ago

Hey man I love Keybase so far, I'm really glad I finally got in a few weeks back. Keep up the good work!

tomjen34• 11 years ago

I hadn't really heard about keybase yet, but does it solve the only problem worth solving in encryption? Does it allow me to take any email address and give me back a private key that only the recipient can use?

If I wanted to know which public key to use I would just look at the recipients public website or ask that person through a phone.

The problem is that people don't create keys because nobody ever send them anything encrypted and people don't send anything encrypted because nobody ever sends anything encrypted.

But if keybase is just another storage for keys, what is the point? Especially if it is going to add a pointless waiting list that is just going to make the problem of not having a key even worse.

mayniac• 11 years ago

Easier PGP programs would increase the use of encryption, especially post-Snowden. I've walked people through using GPG4WIN/Kleopatra and it took a good half hour of explaining how everything works. People care about privacy, but unfortunately not enough to go through the hassle of manually encrypting everything.

kgo• 11 years ago

Keybase lets you do some key stuff, but the bigger feature is that it provides a bunch of ways to authenticate the source of a key above and beyond the WoT and getting into the strong set. Authentication is an inherently hard problem. With keybase you can, for example, see that the key that you want to use to send an encrypted email to x@example.com's website is owned by someone who also controls x@example.com's twitter, reddit, github accounts, web-site, etc, making it less likely that there's a MiTM going on.

zobzu5• 11 years ago

keybase proves who you are.. if you trust keybase

sergiosgc• 11 years ago

Thanks for the opportunity to try out Keybase. Great work.

The only question, but really important is: What is Keybase's business model? How will you make your living? It's a great service, I'd love to build upon it (my company does email as a service), but that step requires knowing you'll still be here a few years from now.

malgorithms4• 11 years ago

Early, while working on Keybase, I answered it here:

https://github.com/keybase/keybase-issues/issues/788

Technically, not a lot has changed. We're still just putting our own money into it. However, we just added 3 people full-time and 1 person part-time, and so our costs have gone up. I'll admit, we only did this when we got an idea that we thought could turn Keybase into a business.

In a few months we'll be launching a tangential idea - more than just a PGP key directory. This product will let you do some neat things with data backup and signed (possibly encrypted) file hosting and message spooling. It has nothing to do with email, but it requires a real PKI. I'll save the specifics for a big announcement, but the pricing model will reflect our costs with room to make money. More per gig than Dropbox and far less than Tarsnap.

Should the "business" fail, we'll be back to where we were when I wrote the above answer.

feld• 11 years ago

My keybase.io account is useless because of an error I cannot comprehend. I've never had a problem with my key, and it was working just fine when I signed up!

  Your public key appears corrupted (no valid primary key self-signature)

edit: my self signature is fine, as far as i can tell

https://pgp.mit.edu/pks/lookup?op=vindex&search=0x983B64501F...

maxtaco• 11 years ago

I moved this to an issue on Github [1]. The key you uploaded to our server has a UID that expired on 2014-11-09. The key you linked to on the MIT key server has updated self-signatures (and subkeys), so doesn't have this problem.

[1] https://github.com/keybase/keybase-issues/issues/1410

peckrob• 11 years ago

Just wanted to say thanks for the chance to try it out. Looks pretty awesome!

jmccree• 11 years ago

I was initially skeptical of Keybase, but I was happy to see the comments on HN of letting people use keybase without installing the CLI client were listened to. Seeing how many of my friends are on keybase now, that never had gpg setup before, I can't help but think it's filling a need that's otherwise unserved.

malgorithms4• 11 years ago

A lot of people are doing it this way: a GPG user can join Keybase via the website, without installing any Keybase client. When it comes time to prove something with their private key (say, their twitter account), the site shows them what to do, using bash/GPG/cURL.

It's pretty straightforward if you already have a key pair / GPG installed. There's no Keybase software to run, and the site basically acts like a todo list / tutorial.

ApolloRising• 11 years ago

Looking forward to trying out Keybase, thank you for opening it up to HN members.

iamcreasy• 11 years ago

Thank you for the opportunity. I've sent request.

halostatue• 11 years ago

How hard would it be to add support for RubyGems certs being added to keybase? I’d love to publish the public cert somewhere without putting it in each repo.

mootothemax• 11 years ago

Is it possible to have a PGP-powered layer that requires close to no setup from the end user?

This seems to be the issue, and until the encryption is, in effect, totally invisible to the average person on the street, I'm not sure we'll see widespread deployment.

felixhammerl6• 11 years ago

your no setup scenario would be when security is handled on the host, which is not really an option for email w/ PGP. if you want gmail to do your de/encryption, you might as well use what you currently have with TLS

diafygi• 11 years ago

Fun facts about GPG's public key infrastructure:

1. The protocol used to gossip public keys in the GPG keyserver pool is completely undocumented[1].

2. The protocol for uploading and downloading public keys from the pool only ever made it to draft stage, and is now very outdated[2].

3. Because the keyserver protocols are not establish, there is only one implementation that is written in OCaml (luckily it is still maintained)[3].

Luckily, these issues are fixable. We just need to spend the resources to fix them. What if GPG had the same resources as WhatsApp?

[1] https://lists.nongnu.org/archive/html/sks-devel/2014-02/msg0...

[2] http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00

[3] https://bitbucket.org/skskeyserver/sks-keyserver

prohor2• 11 years ago

On thing that always wonders me. Assuming NSA or whatever spying agency is sniffing mail in the Internet, I'm pretty sure that once you use PGP, you are basically a strong suspect for them. Obviously the situation would be different if mail was encrypted by default, but now such people just stand out. Not sure if this is a situation I want to be in...

felixhammerl6• 11 years ago

are you playing devils advocate? this is exactly why it's a good idea to use this stuff even for your normal everyday traffic, so that the ones that really need to use it don't stand out. same goes for pretty much every form of encryption.

your point is well taken, but it's not what we're discussing here. lots of people have written lots of essays about this :)

celticninja• 11 years ago

they have openly said that people who use encryption are of interest to them, or at least their communications are. however this is easily solved if there is wide enough adoption. If I encrypt the shopping list that I send to my other half, or I encrypt the text messages i send siblings or any text communication to anyone, and there are 100's of 1000's who do the same it becomes impossible to store/monitor and decrypt all that information. it would essentially overwhelm them with data, which even if they managed to decrypt (through the theft of private keys or a serious brute force attack) would be of no value other than to prove the task a waste of time.

prohor2• 11 years ago

Agree, if mail encryption becomes common, then it is completely different story.

lstepniewski• 11 years ago

"We make the client available on all relevant platforms, desktop, Chromebook, Android, iOS, Windows phone."

And on the https://whiteout.io/ website: Chromebook, Android, iOS, Web, Windows and Firefox OS.

So no Linux version at all??? Isn't Linux a relevant platform?

thefreeman• 11 years ago

It's not "Chromebook" it's Chrome App (aka extension). So it runs in any (non-mobile) Chrome browser.

mbel• 11 years ago

OS X is also missing, isn't OS X a relevant platform?

Of course both are relevant, they just went for the most popular platforms first, plus FF OS, which probably was a kind of low handing fruit due to its HTML5 apps.

felixhammerl6• 11 years ago

the chrome app will run both on linux and mac os. and windows. and the chromebook. same does the web app. one of the marvels of the modern web :)

schoen• 11 years ago

I'm especially sad to see "desktop" used as a synonym for "Windows".

e12e3• 11 years ago

This is why it matters that we say GNU/Linux, not just "Linux". Android and Chromebook run the Linux kernel. As well as Firefox OS AFAIK.

TomMasz• 11 years ago

I have Exchange/Outlook (w/Gpg4Win) at work and OS X Mail w/GPGTools) at home. I can't send GPG signed/encrypted emails between work and home. But I can with the S/MIME implementation built into Outlook (w/certificate from Comodo, hmmmm). Add-ons for email programs just don't seem to be the answer, at least so far.

Gumbi• 11 years ago

Hi Tom, gpg4win is really awkward in terms of compatibiltiy (beside other lacking features). I exchange a lot of encrypted mails with different people - among them Apple users. Take a look at gpg4o (http://www.gpg4o.com) which is my preferred solution.

Gumbi

ukigumo• 11 years ago

Assuming you have access to your mail server to make the necessary configurations, wouldn't something like ciphermail's (https://www.ciphermail.com/) pgp /smime gateway make it easy for joe user to have encrypted email?

I've used it in my own setup and think it works quite nicely so far but then again I only have 8 people using it.

moxie2• 11 years ago

I'm not really positioning TextSecure as a secure mail solution, but this article says that the TextSecure protocol can't support asynchronous operations or federated namespaces. To clarify, that's incorrect, the TextSecure protocol was actually designed from the ground up for asynchronous communication, and is designed to support a federated namespace: https://whispersystems.org/blog/asynchronous-security/

That leaves these points for PGP:

It’s been around for a long time, so it’s cryptographically well understood.

Yes, but it's cryptographically well understood not to provide the properties we need.

There are a variety of implementations and there is a small but vibrant and highly committed developer community. A small but active and committed user community.

Small can't be emphasized enough, and this is the most important part to me. I think people have a tendency to look at PGP and conclude that while it might be painful, we have to put up with it for backwards compatibility. The truth is that it's a protocol with few contemporary redeeming qualities, and an active user base of ~50k. So why bother with backwards compatibility?

zobzu5• 11 years ago

Still would like to see your source for the "50k active user base" claim.

viccuad• 11 years ago

He doesn't have one. Sometimes I wonder how difficult would be to sneak a sabouteur into the crypto community, who advocated for ditching proven and safe crypto tools, wanted his solutions on top of centralized servers owned by others, opposed distribution of signed binaries in FOSS markets, recommended the people to use stock OSs with binary and who-knows-what google libs inside, instead of installing the free counterparts, etc..

Is like people have forgotten that they should trust only the algorithms and the implementations, not the persona behind them. And that persona, should be the first saying "don't trust me! trust my algorithms!".

mnem• 11 years ago

I think he's referring to the number of keys in the "strong set" as described here: http://pgp.cs.uu.nl/plot/

lmm2• 11 years ago

Yes, but it's cryptographically well understood not to provide the properties we need.

If you're talking about perfect forward secrecy, surely that's fundamentally impossible for a protocol that is both asynchronous and decentralized? If one party can only send a single async message to another, then that message necessarily must be decryptable by that second party using only what that second party knows, and you lose PFS. PFS only works for synchronous communications where both parties can use a key exchange protocol, or centralized communications where an asynchronous message can be implemented as a synchronous message to a central authority. No?

pbsd• 11 years ago

It is not fundamentally impossible. It has been shown [1] that forward-secure public-key encryption can be done without the key size blowing up with the expected number of encrypted messages, though it's not very practical. The trivial case of §3.2, in which the key is simply a tuple of N keys which are erased as messages are encrypted/decrypted, seems similar to what TextSecure does.

[1] https://eprint.iacr.org/2003/083

moxie2• 11 years ago

https://whispersystems.org/blog/asynchronous-security/ https://whispersystems.org/blog/advanced-ratcheting/ https://whispersystems.org/blog/simplifying-otr-deniability/

IgorPartola2• 11 years ago

It's actually quite simple. PGP/GPG is the equivalent of the S in HTTPS. It's a trust model + ciphersuite + tools and libraries for using it. Would you ask your users to use TLS directly? No, you would not. Would you be surprised if the users hated using TLS directly? Nope.

What PGP/GPG actually needs is a nice UI. What's been holding it back is webmail. PGP and webmail are incompatible. Now that mobile is starting to take over people are using non-web based mail clients again and PGP becomes viable again. Imagine integrating Keybase with Mail.app. Now when you send an email to people it's automatically encrypted and verified. As you compose your message you can see that <igor@example.com> is known on Twitter as @exampleIgor and on Facebook as /exampleIgor and on HN as exir.

This is where we should be heading: building on top of the PGP protocol (and fixing the protocol where 20 year old warts are popping up, such as issues with forward secrecy).

martinkl• 11 years ago

The problem is that, on the whole, users simply don't care. They have more important things to worry about than email encryption (you know, stuff like spouse, kids, mortgage, partying, etc).

The only way I can see end-to-end crypto really being adopted is if it's turned on by default everywhere. The selling point can't be the security, because people don't care about security -- the selling point has to be something else. Anything that requires a manual adoption step is going to automatically limit itself to a very niche audience.

IgorPartola2• 11 years ago

Which is why I proposed that UI: it works automatically. While using the system, it simply indicates to you as you compose the message "Yes, the email address you are sending mail to belongs to the person you intend to message" or "No, that email address belongs to someone else" or "This is a brand new email address." This way when you are emailing your lawyer to set up a will, or you email your accountant with your tax info, you can be sure that (a) you are emailing just the right person and (b) that only they can read the communication.

While setting up the system, you are simply required to link your identity. Twitter, Facebook, LinkedIn, GMail, HN, the government all should allow you to easily link your identity. This should be a normal part of your account creation (this can tie in nicely with another change: getting rid of passwords and using a browser UI for identifying yourself a la Persona, but PGP based). Basically when signing up for Twitter, it should optionally let you upload one of your public keys (via a nice browser UI no less). Twitter (Facebook, GMail, etc.) would then expose a nice API for querying by public key fingerprint: "Who has 0xDEADBEEF?" => "@DeadBeef". Revocation, key updates, all that should be automatic: you revoke your public key and issue a replacement, all your services update automatically.

This is the point where lots of people will raise concerns about privacy: "This means Twitter now must have access to my GMail account! WTF?!". No. This process must be voluntary and optional. If you want to have 200 different identities online, go for it. I don't care to know your real name, I just care to know that I am talking only to the person I intend to talk to. Think emailing a well known developer on GitHub, having never met them. You don't need their real name, you are only interested in them in so far as they publish OSS on GitHub. This allows you to prove that github.com/example is @example on Twitter, example@example.com, example@gmail.com, and HN user "example".

And the benefit to "regular Joe" is that when he emails his accountant, he can now send his credit card number and SSN without fear of eavesdropping.

XYEaQMZJvS• 11 years ago

Why do hip startups always use the .io domain? It seems to have something to do with GitHub, but I don't know what.

serf• 11 years ago

cheap, newish (so simpler names are available), trendy, technically relevant phrase (i/o).

eyeareque• 11 years ago

Would you trust your life on a protocal such as HTTPS?

How often is https broken? It seems like every six weeks OpenSSL comes out with a new advisory full of vulnerabilities. I'm assuming that the world powers out there have zero days in OpenSSL, they attack SSL and VPNs all day long. People will be harmed if they trust HTTPS to secure their correspondence.

It is great that you're trying to give PGP a new life, but you're weakening it by using a vulnerable protocol with it. The weakest link will always break first.

upperechelon• 11 years ago

The main crux of this whole post is that PGP is still good it's just that it's hard to use and there's no mobile support. Unfortunately for whiteout, there are many different mobile PGP implementations that do everything these guys are planning to (like automatic key lookup) that already exist today. Notably among them K9 + OpenKeychain, which already support keybase.io and HKPS.

People who say that security is meant to be hard are missing the point, OTR has been around for a long time and is not only much more secure than PGP but more useable. If you want truly secure asynchronous messaging you should checkout Pond by Adam Langley, which is arguably the only traffic analysis and metadata resistant messaging protocol on the planet. Unfortunately PGP has been designed in a way that careful key management is pretty much a requirement if you want. PGP key verification is extremely painful on every implementation I've ever seen, and unless you do it you are vulnerable to extremely potent attacks which are the result of plaintext key sharing algorithms like HKP and LDAP.

I'm with moxie on this one, I get sad that people are still trying to build modern 'secure' architecture based on a ~20 year old cryptosystem. It sets everyone who cares about useable security back because you are continually encouraging people to cling on to the old paradigm. Unfortunately there is no clear, universal successor to the PGP kingdom... yet.

PGP: There’s Life in the Old Dog Yet

Related Stories