Secure PGP Sync
blog.whiteout.io
Secure PGP Sync
1–10 of 15 posts
Re: Secure PGP Sync
#2I don't see how this is any significant improvement over just having passphrase protected private key in your dropbox. In both cases some cloud server has similar access to encrypted keyfile.
Re: Secure PGP Sync
#3Strangely, I was thinking about this problem this morning. A "keychain code" (aka, randomly generated passphrase) doesn't seem any more usable. It moves from "it's hard to securely sync private keys across devices", to "it's hard to securely sync long passphrases between devices".
Why not a user chosen passphrase, with pretty extreme key stretching (w seed)? Allow fetching the encrypted key with any piece of ID similar (email, twitter handle). The key stretching makes brute-force or dictionary attacks pretty much impossible.
Re: Secure PGP Sync
#4Strangely, I was thinking about this problem this morning. A "keychain code" (aka, randomly generated passphrase) doesn't seem any more usable. It moves from "it's hard to securely sync private keys across devices", to "it's hard to securely sync long passphrases between devices". Why not a user chosen passphrase, with pretty extreme key stretching (w seed)? Allow fetching the encrypted key with any piece of ID simil…
> Why not a user chosen passphrase, with pretty extreme key stretching (w seed)?
Because users simply cannot be trusted to provide secure passphrases. Never, ever store or transmit data secured with a passphrase; it will be broken at some point.
It's okay to secure data on a user's device with a passphrase; that requires that an attacker access the device itself.
To move data between devices, consider systems like JPAKE and/or using NFC to communicate between the devices themselves.
Re: Secure PGP Sync
#5I don't see how this is any significant improvement over just having passphrase protected private key in your dropbox. In both cases some cloud server has similar access to encrypted keyfile.
Because if the user chooses a bad passphrase (hint: he will) then his key will be compromised forever.
Users will choose 'password'; they'll choose '12345'; they won't choose 'VPSJjNwytizY7vtGzRv208' or 'cZD2N49caaSYkDuWZMHuyiuKuk6AhA5jdC29g3moHmX' (128- and 256-bit, respectively).
Re: Secure PGP Sync
#6I don't see how this is any significant improvement over just having passphrase protected private key in your dropbox. In both cases some cloud server has similar access to encrypted keyfile.
Because if the user chooses a bad passphrase (hint: he will) then his key will be compromised forever. Users will choose 'password'; they'll choose '12345'; they won't choose 'VPSJjNwytizY7vtGzRv208' or 'cZD2N49caaSYkDuWZMHuyiuKuk6AhA5jdC29g3moHmX' (128- and 256-bit, respectively).
So make an app that creates random passphrases. You don't need completely new protocol for that.
Re: Secure PGP Sync
#7I don't see how this is any significant improvement over just having passphrase protected private key in your dropbox. In both cases some cloud server has similar access to encrypted keyfile.
Because if the user chooses a bad passphrase (hint: he will) then his key will be compromised forever. Users will choose 'password'; they'll choose '12345'; they won't choose 'VPSJjNwytizY7vtGzRv208' or 'cZD2N49caaSYkDuWZMHuyiuKuk6AhA5jdC29g3moHmX' (128- and 256-bit, respectively).
[deleted]
Re: Secure PGP Sync
#8Earlier quoted context omitted.
Because if the user chooses a bad passphrase (hint: he will) then his key will be compromised forever. Users will choose 'password'; they'll choose '12345'; they won't choose 'VPSJjNwytizY7vtGzRv208' or 'cZD2N49caaSYkDuWZMHuyiuKuk6AhA5jdC29g3moHmX' (128- and 256-bit, respectively).
So make an app that creates random passphrases. You don't need completely new protocol for that.
As far as I can tell, that's exactly what TFA proposes (while also trying to be user-friendly).
> You don't need completely new protocol for that.
You need a protocol because protocols can be audited and built upon. User-interaction protocols are very much a part of crypto and, IMHO, trying to minimize the user-error surface is critical for cryptography's development.
This is about bringing crypto to the average Joe. You think they're going to download several heterogeneous tools, learn to use them, devise their own security protocol... and also not mess anywhere in the process? I don't think so!
If a protocol+app saves them the hassle and lowers the chance of mistakes, why not?
Also, as they point in the article:
> One could simply throw out the last 30 years of protocols like SMTP, IMAP and PGP and reinvent the wheel like DarkMail, but we at Whiteout believe in building on existing standards, since they aren't going away any time soon.
This would merely be another layer at the stack.
Re: Secure PGP Sync
#9Sooo what happens when whiteout gets an NSL and suddenly the "we don't store the keycode on our server.... trust us" mantra gets thrown out the window? Why invent your own authentication protocol with AES-256-GCM when this seems like a clear-cut case for TLS? Why use PBKDF2 over Scrypt?
Re: Secure PGP Sync
#10I don't see how this is any significant improvement over just having passphrase protected private key in your dropbox. In both cases some cloud server has similar access to encrypted keyfile.
Because if the user chooses a bad passphrase (hint: he will) then his key will be compromised forever. Users will choose 'password'; they'll choose '12345'; they won't choose 'VPSJjNwytizY7vtGzRv208' or 'cZD2N49caaSYkDuWZMHuyiuKuk6AhA5jdC29g3moHmX' (128- and 256-bit, respectively).
Yeah but no user is ever going to be able to remember either of those passwords, even the website encourages people to write it down. So when the FBI raids Johnny's house and they find his post-it note next to his computer he's gonna be in a lot of trouble. And before you mention password management applications... that would also be a solution for the 'users pick bad passwords' problem