PGP: There’s Life in the Old Dog Yet
blog.whiteout.io
blog.whiteout.io
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.
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.
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.
Now they communicate with me always encrypted, automatically. They don't have to know any details about encryption, except that they occationally have to type in their password.
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.
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.
Your public key appears corrupted (no valid primary key self-signature)
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x983B64501F...
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.
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?
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!".
If you take every key uploaded to the key servers ever, then it's more like 4 million. However most of those aren't active.
TextSecure, in contrast, has vastly more users than PGP has ever had, despite being a lot newer.
Sometimes I wonder how difficult would be to sneak a sabouteur into the crypto community, who advocated for ditching proven and safe crypto tools
Sometimes I wonder if the best way to sabotage the crypto community would be to fill it with people aggressively advocating for obsolete technologies that have zero chance of any meaningful impact :)
Moxie is unusual in the strong crypto space, in that he is willing to make pragmatic engineering choices in order to ship a working product. That is why he and his team have had a lot more impact than most others have.
On textsecure usage
In my experience, very very few people actually sign keys, and few people upload them on keyservers. Also, I know very very few people who use textsecure. I used it for a few month, trying to get others to talk to me with it and gave up. And I'm in the bay area working with IT people, most of my friends are IT people mind you, we're exactly the people who try that stuff all the time.
It doesn't mean its bad tech or a bad attempt at all, heck, I would LOVE for it to catch up. But I seriously doubt it has 4 millions active users or more.
On PGP usage
From a key server perspective there are still a large number of keys being downloaded, refreshed and updated daily.
Let's look at Mozilla's stats and they just seem to peer with one low traffic guy and themselves... http://gpg.mozilla.org/pks/lookup?op=stats that's 1k new keys a day, and about 500 updated a day. We're far from the 50k claim since it would reach that in 50 days no matter what.
Of course saying there's only, say a few millions PGP users doesnt mean AT ALL the same as 50k.
On misinformation
Thus I'm calling bullshit. Purposefully misrepresenting data (large order of magnitudes, at that) is a big minus in my book. Being well-known shouldn't mean you can tell people bullshit - if anything, you have a greater responsibility when you do.
The 4 million figure was total users of GPG ever, not TextSecure. TextSecure for Android has had about 1 million installs.
However, it's also been integrated into the Cyanogen mod which added about 10 million users, and the tech has been integrated into WhatsApp, which got the underlying crypto code (though not the UI) to about 400 million+ users.
So if by "TextSecure" we mean the technology rather than the actual UI widget code, which is generic anyway, then it's in a whole other league by orders of magnitude.
Or least, that was my understanding of your previous comment You're basically kinda saying there is between 11millions and 400 millions users, and, you know, i dont trust that at all and would compare it to notepad/paint being installed on windows but not actually used.
Anyway, whichever tech really catches up would be a good thing. I just dislike the manipulation of information for marketing of one tech over another for fame, money, power etc. Specially when that means bad mouthing free and open source projects :)
What it really means is that people don't use the web of trust that much.
Most people I encounter do not sign keys, they just verify they've seen the same key before.
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?
So, my laptop is off-line, and I have access to a recipients public key. How do I encrypt my message, before moving it to a machine that's on-line for sending via smtp?
This isn't really asynchronous in the sense that email is (stop-forwards-stop-forward). Nor does it appear to work for writing and encrypting an sms while on an air-plane (the message will only be encrypted when the pre-key can be retrieved).
It doesn't seem quite fair to claim (or rather imply) that the scheme does for email what pgp does.
It also carries more state around (on the "server" and on the "client") so it's not decentralized. It might be closer to pgp than classic otr, but it's not really a replacement for pgp as far as I can tell.
The pre-key is needed when you have never talked to someone (I guess it's also needed when the last conversation is really old, I haven't dug throuh the code); it's a necessary bootstrap step. After that all you need is inside your client.
> So, my laptop is off-line, and I have access to a recipients public key. How do I encrypt my message, before moving it to a machine that's on-line for sending via smtp?
You encrypt it on your laptop, transfer the encrypted blob to your online machine and send the blob through it. All state is managed by your laptop, intermediary machines are just forwarding the message (which is merely an opaque blob at this point, possibly with a "destination" to ease routing to the recipient(s)).
> Nor does it appear to work for writing and encrypting an sms while on an air-plane
From a user pov, there is no difference between:
- I type the message and hit send, the message is encrypted now and sent when I have connectivity
- I type the message and hit send, the message is encrypted and sent when I have connectivity
The problem here will not be technical but purely UX (the software has to allow deferring encryption and sending when resources are available)
> It also carries more state around (on the "server" and on the "client") so it's not decentralized.
The little state there is on the server really doesn't sound centralized to me in that it is really simple (the server must be able to store a given list of blobs sent by the client, and the server must not send twice the same blob, ever) and a client can choose any server (there is no concept of "registration", but the client has to trust the server it will not misbehave).
The state on the client is really client-specific, it wouldn't make sense to share a client's ratchet state: as a comparison you wouldn't share the current bucket list of your DHT client with other machines because it doesn't make sense, you would rebuild it from scratch on another machine. Effectively this means every device of yours is considered another independent "peer".
I think it's important at this point to say that this mechanism is the Axolotl ratchet (more details here: https://github.com/trevp/axolotl/wiki). It only describes how to exchange encrypted messages between two DH keys, asynchronously, and with forward secrecy. It doesn't care about :
- what is the relationship between DH keys ("should I encrypt to 2 DH keys because they belong to the same user ?")
- how do get someone's key, and is it the good one (the key distribution management)
- how can I have a coherent message history between my phone and my computer
These are all real problems that TextSecure aims to solve, but they're a whole another thing.
Well, no. It's needed when you client has never talked to someone. If you have a pad, a phone and a laptop, they all need a pre-key to talk to the same person. If the person's server is down, the system breaks down (you can't have just anyone mirror the pre-keys).
> From a user pov, there is no difference between: > > - I type the message and hit send, the message is encrypted now and sent when I have connectivity > > - I type the message and hit send, the message is encrypted and sent when I have connectivity
Perhaps not. But there's a difference between being alerted that you can't reach the recipient securely before you type the message, and getting that message (no pre-key available) after you've taken the time to write the message.
Not to mention that hopefully the device has FDE, so there aren't any plain-text messages around for when you go through customs, or when someone steals your phone etc. But I'll concede that device security is probably outside the realm of what a message system should deal with.
Don't get me wrong, I welcome improvements like this -- I just don't think it's comparable to pgp (which is both good and bad).
There's maybe a case for a protocol that offers both (though in practice I've just seen people sign their OTR key fingerprints with their PGP key), but that goes against the simplicity that you're emphasising.
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...
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."
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.
Let's put things in context. Would you trust WhatsApp to be part of the US nuclear launch chain? Or talkes between the leaders of US, France, China, and North Korea.
The type of encryption used in whatsapp is not something I want to authenticate in anything that has to be dormant and used in an emergency without a network, but that doesn't mean it is bad crypto.
Yes, why not? You still need to ensure that the people involved with whatsapp can be trusted, but even the NSA can't do that in every case (ie Snowdon).
http://geer.tinho.net/geer.rsa.28ii14.txt
https://encrypted.google.com/search?hl=en&q=site%3Ahttp%3A%2...
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.
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).
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.
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.
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.
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.
Huge does not mean powerful when it is hard to mix and match (and limit) the functionality.
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-...
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?
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.
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.
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.
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.
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.
your point is well taken, but it's not what we're discussing here. lots of people have written lots of essays about this :)
Gumbi