8 ms·

PGP: There’s Life in the Old Dog Yet

83 points by onli 12y ago

zvrba 12y ago
Is anybody working on making identity-based encryption mainstream?
- onli 12y ago
  Are you thinking of something like https://keybase.io/ https://keybase.io/?
- bradleyjg 12y ago
  IBE requires a trusted third parties to issue private keys to users. That's essentially the lavabit model with slicker math.
cpks 12y 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.
- felixhammerl 12y ago
  website update is coming soon :)
wuschel 12y 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."
- Dylan16807 12y 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.
- tomjen3 12y 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.
  - Retric 12y 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.
    - tomjen3 12y ago
      WhatsApp.
      - Retric 12y ago
        WhatsApp fails freedom and arguably security. 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.
        tomjen3 12y ago
        No and yes. 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).
zby 12y 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 12y 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.
  - zby 12y 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.
    - felixhammerl 12y ago
      we're using and contributing to openpgp.js and so far this has worked pretty good for us, because it provides a sane API, properly documented, coherent code style, CI tested. here's a snippet for decryption and signature checking in Whiteout Mail: https://github.com/whiteout-io/mail-html5/blob/master/src/js/crypto/pgp.js#L314L351 https://github.com/whiteout-io/mail-html5/blob/master/src/js...
malgorithms 12y 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 12y 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.
  - malgorithms 12y 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.
mootothemax 12y 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.
- felixhammerl 12y 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 12y 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/msg00007.html https://lists.nongnu.org/archive/html/sks-devel/2014-02/msg0... [2]: http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00 http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00 [3]: https://bitbucket.org/skskeyserver/sks-keyserver https://bitbucket.org/skskeyserver/sks-keyserver
prohor 12y 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...
- felixhammerl 12y 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 12y 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.
  - prohor 12y ago
    Agree, if mail encryption becomes common, then it is completely different story.
lstepniewski 12y ago
"We make the client available on all relevant platforms, desktop, Chromebook, Android, iOS, Windows phone." And on the https://whiteout.io/ 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 12y ago
  It's not "Chromebook" it's Chrome App (aka extension). So it runs in any (non-mobile) Chrome browser.
- mbel 12y 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.
  - felixhammerl 12y 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 12y ago
  I'm especially sad to see "desktop" used as a synonym for "Windows".
- e12e 12y 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 12y 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 12y 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 http://www.gpg4o.com) which is my preferred solution. Gumbi
ukigumo 12y ago
Assuming you have access to your mail server to make the necessary configurations, wouldn't something like ciphermail's (https://www.ciphermail.com/ 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.
moxie 12y 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/ 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?
- zobzu 12y ago
  Still would like to see your source for the "50k active user base" claim.
  - deleted 12y ago
    [deleted]
  - viccuad 12y 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!".
IgorPartola 12y 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 12y 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.
  - IgorPartola 12y 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 12y 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 12y ago
  cheap, newish (so simpler names are available), trendy, technically relevant phrase (i/o).
eyeareque 12y 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 12y 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.

83 points by onli 12y ago

zvrba 12y ago

Is anybody working on making identity-based encryption mainstream?

onli 12y ago
Are you thinking of something like https://keybase.io/ https://keybase.io/?
bradleyjg 12y ago
IBE requires a trusted third parties to issue private keys to users. That's essentially the lavabit model with slicker math.

cpks 12y 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.

felixhammerl 12y ago
website update is coming soon :)

wuschel 12y 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."

Dylan16807 12y 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.
tomjen3 12y 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.
- Retric 12y 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.
  - tomjen3 12y ago
    WhatsApp.
    - Retric 12y ago
      WhatsApp fails freedom and arguably security. 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.
      - tomjen3 12y ago
        No and yes. 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).

zby 12y 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 12y 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.
- zby 12y 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.
  - felixhammerl 12y ago
    we're using and contributing to openpgp.js and so far this has worked pretty good for us, because it provides a sane API, properly documented, coherent code style, CI tested. here's a snippet for decryption and signature checking in Whiteout Mail: https://github.com/whiteout-io/mail-html5/blob/master/src/js/crypto/pgp.js#L314L351 https://github.com/whiteout-io/mail-html5/blob/master/src/js...

malgorithms 12y 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 12y 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.
- malgorithms 12y 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.

mootothemax 12y 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.

felixhammerl 12y 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 12y 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/msg00007.html https://lists.nongnu.org/archive/html/sks-devel/2014-02/msg0... [2]: http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00 http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00 [3]: https://bitbucket.org/skskeyserver/sks-keyserver https://bitbucket.org/skskeyserver/sks-keyserver

prohor 12y 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...

felixhammerl 12y 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 12y 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.
- prohor 12y ago
  Agree, if mail encryption becomes common, then it is completely different story.

lstepniewski 12y ago

"We make the client available on all relevant platforms, desktop, Chromebook, Android, iOS, Windows phone." And on the https://whiteout.io/ 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 12y ago
It's not "Chromebook" it's Chrome App (aka extension). So it runs in any (non-mobile) Chrome browser.
mbel 12y 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.
- felixhammerl 12y 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 12y ago
I'm especially sad to see "desktop" used as a synonym for "Windows".
e12e 12y 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 12y 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 12y 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 http://www.gpg4o.com) which is my preferred solution. Gumbi

ukigumo 12y ago

Assuming you have access to your mail server to make the necessary configurations, wouldn't something like ciphermail's (https://www.ciphermail.com/ 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.

moxie 12y 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/ 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?

zobzu 12y ago
Still would like to see your source for the "50k active user base" claim.
- deleted 12y ago
  [deleted]
- viccuad 12y 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!".

IgorPartola 12y 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 12y 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.
- IgorPartola 12y 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 12y 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 12y ago
cheap, newish (so simpler names are available), trendy, technically relevant phrase (i/o).

eyeareque 12y 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 12y 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.