4 ms·

We're trying an approach with http://parley.co http://parley.co that involves storing a symmetrically encrypted OpenPGP keyring on the server for our users. Tha

We're trying an approach with http://parley.co http://parley.co that involves storing a symmetrically encrypted OpenPGP keyring on the server for our users. That, combined with a UI that automatically takes care of key sharing and discovery, results in a system that's easy for the average user, integrates with the existing PGP ecosystem, and is at least as secure as a symmetric scheme (like symmetric systems, the strength is limited by the passphrase, but at least users can each have their own).

devinhosea 13y ago
now THAT is the way to do it! Yes, the average user has trouble grasping the CRITICAL IMPORTANCE that the user, AND ONLY THE USER, must physically hold the private key. There's no problem with having the public keyring in the cloud, and I don't even see any reason to keep it encrypted. It's called the PUBLIC key for a reason, to paraphrase Whit Diffie. You guys are on the right track...tools that make REAL 4096-bit PKE EASY are what are needed (Certainly it is an understatement to say that a 4096-bit elliptical curve DH cryptogram is "at least as secure as symmetric keys" - indeed, symmetric schemes are several orders of magnitude weaker, even with the same size passphrase) . But users will have the "inconvenience" of having to store their PRIVATE KEY on all their devices; but hey, that's not much work to be virtually impregnable. I applaud Parley's efforts!
- kbaker 13y ago
  minor nitpick - it sounds like parley is storing the encrypted private keys on their server, encrypted with the user's passphrase. This method is the best tradeoff with cloud encryption IMO - convenience of having the key file accessible anywhere, even if it is not as secure as copying it yourself to all your devices. Also, much much better than using symmetric keys.
  - napoleond 13y ago
    Our thoughts exactly :)
- napoleond 13y ago
  Thank you for the kind words, but just to be crystal clear: we are storing the users' private keys on the cloud, hence the symmetric encryption. It's certainly a trade-off, and not the right option for everyone, but it lowers the barrier to entry for OpenPGP enormously.
  - Osmium 13y ago
    Really admire what you're doing here, but proposed pricing seems off (just my opinion). If you think we'd be better off moving to a "encrypted by default" world, then limiting paying users to sending 150 messages a month isn't a good way to do it! Especially when I know it doesn't cost that much to do so.
    - napoleond 13y ago
      I appreciate the feedback! Pricing is tricky, and we're open to suggestions--our challenge is basically to earn most of our profit from business users while keeping it inexpensive for consumers. Maybe the number of messages is the wrong way to separate the two camps, though. Any ideas? (Is 150 messages/month really limiting for average users? I don't think I've sent anywhere near that much personal mail this month, but I may be an anomaly.) EDIT: I forgot to mention that whichever way we end up doing it, the personal plan will be free for anyone who signs up for the mailing list before August 1.
      - lmm 13y ago
        My first thought is number of recipients. If you allowed low-tier users to send messages to e.g. 5 people at a time, and any more required the business plan, that seems like a good way to separate the two.
        Osmium 13y ago
        Number of recipients seems like a good idea for separating personal and business to me too. Personally, I only use PGP for emails with my partner, but we definitely send way in excess of 150 messages a month. I'm all for a world where people start using encryption as a matter of course, so I really the OP's product works out. It'll finally get rid of that "you must have something to hide" mentality, when all you really want to do is protect yourself from the odd security vulnerability or a grumpy sys admin with an axe to grind!
- jlgaddis 13y ago
  >> storing a symmetrically encrypted OpenPGP keyring on the server > now THAT is the way to do it! Um, no. No, it absolutely is not. See also: Hushmail.
  - napoleond 13y ago
    One big difference with Hushmail is that they are a web app, so they can be (and have been) compelled by law enforcement to serve malicious code to certain users. Parley is a standalone desktop/mobile app, so it would be difficult for that scenario to occur. The passphrase is also PBKDF2'd on the client, so the server never sees it.
scoot 13y ago
I'm all for anything that makes moving one's private key between devices easier, and I understand that you've made a conscious compromise between security and usability, but wouldn't it be possible to achieve both goals, for example by enabling private key syncronisation between devices without the key having to be uploaded to a third-party server? This would also eliminate the need for the additional passphrase, as the point-to-point key trasfer could by programatically encrypted / decrypted without user intervention.
- napoleond 13y ago
  That's a great idea, and I see no reason that it couldn't be done. Removing the centralized target would obviously be beneficial, but I'm not sure it would be possible to increase security for individual users that much: If the only common information between the two devices is what's in the user's head (email, password) then you'd still need a server to negotiate the exchange (by telling the new device where to find the first one) which would leave the whole system vulnerable to many of the same targeted attacks as the centralized design (MITM or malicious actor at the server trying to brute force individual keys).
  - scoot 13y ago
    I agree, but it should still be possible mitigate those sorts of threats without the user needing anything else in thier head (at least more than temporarily :-), even if the password for the negotiation was successfully brute-forced / MITM'd so that a foreign device could initiate a private key transfer, and even if the private key exchange itself was MITM'd. Perhaps for example using a one-time shared secret either displayed on one device and entered in the other, or entered by the user on both devices as a temporary pass-phrase. This could then form part of a D-H style key exchange, or even be the encryption passphrase as in your proposed model, but only used temporarily while the private key is transferred, so not having to be remembered by the user for a centrally stored copy of the private key. I appreciate you're probably well down the track on your current model, but it would be really nice to see something like this developed, and ultimately standardised, as like you mention in your manifesto, private key management (and especially transfer and backup) is one of the larger usability barriers to wider adoption of public-key cryptography.

devinhosea 13y ago

now THAT is the way to do it! Yes, the average user has trouble grasping the CRITICAL IMPORTANCE that the user, AND ONLY THE USER, must physically hold the private key. There's no problem with having the public keyring in the cloud, and I don't even see any reason to keep it encrypted. It's called the PUBLIC key for a reason, to paraphrase Whit Diffie. You guys are on the right track...tools that make REAL 4096-bit PKE EASY are what are needed (Certainly it is an understatement to say that a 4096-bit elliptical curve DH cryptogram is "at least as secure as symmetric keys" - indeed, symmetric schemes are several orders of magnitude weaker, even with the same size passphrase) . But users will have the "inconvenience" of having to store their PRIVATE KEY on all their devices; but hey, that's not much work to be virtually impregnable. I applaud Parley's efforts!

kbaker 13y ago
minor nitpick - it sounds like parley is storing the encrypted private keys on their server, encrypted with the user's passphrase. This method is the best tradeoff with cloud encryption IMO - convenience of having the key file accessible anywhere, even if it is not as secure as copying it yourself to all your devices. Also, much much better than using symmetric keys.
- napoleond 13y ago
  Our thoughts exactly :)
napoleond 13y ago
Thank you for the kind words, but just to be crystal clear: we are storing the users' private keys on the cloud, hence the symmetric encryption. It's certainly a trade-off, and not the right option for everyone, but it lowers the barrier to entry for OpenPGP enormously.
- Osmium 13y ago
  Really admire what you're doing here, but proposed pricing seems off (just my opinion). If you think we'd be better off moving to a "encrypted by default" world, then limiting paying users to sending 150 messages a month isn't a good way to do it! Especially when I know it doesn't cost that much to do so.
  - napoleond 13y ago
    I appreciate the feedback! Pricing is tricky, and we're open to suggestions--our challenge is basically to earn most of our profit from business users while keeping it inexpensive for consumers. Maybe the number of messages is the wrong way to separate the two camps, though. Any ideas? (Is 150 messages/month really limiting for average users? I don't think I've sent anywhere near that much personal mail this month, but I may be an anomaly.) EDIT: I forgot to mention that whichever way we end up doing it, the personal plan will be free for anyone who signs up for the mailing list before August 1.
    - lmm 13y ago
      My first thought is number of recipients. If you allowed low-tier users to send messages to e.g. 5 people at a time, and any more required the business plan, that seems like a good way to separate the two.
      - Osmium 13y ago
        Number of recipients seems like a good idea for separating personal and business to me too. Personally, I only use PGP for emails with my partner, but we definitely send way in excess of 150 messages a month. I'm all for a world where people start using encryption as a matter of course, so I really the OP's product works out. It'll finally get rid of that "you must have something to hide" mentality, when all you really want to do is protect yourself from the odd security vulnerability or a grumpy sys admin with an axe to grind!
jlgaddis 13y ago
>> storing a symmetrically encrypted OpenPGP keyring on the server > now THAT is the way to do it! Um, no. No, it absolutely is not. See also: Hushmail.
- napoleond 13y ago
  One big difference with Hushmail is that they are a web app, so they can be (and have been) compelled by law enforcement to serve malicious code to certain users. Parley is a standalone desktop/mobile app, so it would be difficult for that scenario to occur. The passphrase is also PBKDF2'd on the client, so the server never sees it.

scoot 13y ago

I'm all for anything that makes moving one's private key between devices easier, and I understand that you've made a conscious compromise between security and usability, but wouldn't it be possible to achieve both goals, for example by enabling private key syncronisation between devices without the key having to be uploaded to a third-party server? This would also eliminate the need for the additional passphrase, as the point-to-point key trasfer could by programatically encrypted / decrypted without user intervention.

napoleond 13y ago
That's a great idea, and I see no reason that it couldn't be done. Removing the centralized target would obviously be beneficial, but I'm not sure it would be possible to increase security for individual users that much: If the only common information between the two devices is what's in the user's head (email, password) then you'd still need a server to negotiate the exchange (by telling the new device where to find the first one) which would leave the whole system vulnerable to many of the same targeted attacks as the centralized design (MITM or malicious actor at the server trying to brute force individual keys).
- scoot 13y ago
  I agree, but it should still be possible mitigate those sorts of threats without the user needing anything else in thier head (at least more than temporarily :-), even if the password for the negotiation was successfully brute-forced / MITM'd so that a foreign device could initiate a private key transfer, and even if the private key exchange itself was MITM'd. Perhaps for example using a one-time shared secret either displayed on one device and entered in the other, or entered by the user on both devices as a temporary pass-phrase. This could then form part of a D-H style key exchange, or even be the encryption passphrase as in your proposed model, but only used temporarily while the private key is transferred, so not having to be remembered by the user for a centrally stored copy of the private key. I appreciate you're probably well down the track on your current model, but it would be really nice to see something like this developed, and ultimately standardised, as like you mention in your manifesto, private key management (and especially transfer and backup) is one of the larger usability barriers to wider adoption of public-key cryptography.