Secure PGP Sync
blog.whiteout.io
blog.whiteout.io
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.
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.
Extreme key-stretching (w seed) mostly mitigates weak passphrases (I mean extreme stretching, 60s+ of CPU time for each guess). Even a 6 char password would take 100k years of CPU time to brute force. I'm aware if they use "12345" or "password" it'll be crackable, but it's a balance of user friendliness and security.
Am I missing something, genuinely curious.
Well, I did state that the use of NCF or JPAKE would be when moving data between devices; moving data kinda presupposes some sort of communication channel☺
> Neither fit the bill if the goal is user friendly, accessible from anywhere, and backup in case of loss (what they are proposing).
I think that this is a mutual-exclusion situation. If there's remote storage of data, the encryption must be high-entropy, which means that it cannot be user-friendly.
> I'm aware if they use "12345" or "password" it'll be crackable, but it's a balance of user friendliness and security.
I don't believe that's a good enough balance, given that so many users will choose poor passwords. Nor is waiting a minute or more to log into a system particularly friendly (although in the case of backups, maybe they only need to wait that long when accessing those backups).
And of course, with Moore's Law, what took 60 sec today will take 40 sec in a a year and a half and 27 sec in three years,just over a second in a decade and .02 seconds in twenty years; an attacker will be able to make 3,195 guesses per second in 30 years and 184,288 guesses per second in 40 years. Better hope that none of the data stored remotely under that key is still valuable in four decades.
also, nsl? we're german. meh. ;)
"trust us" sucks. period. we can agree on that. https://blog.whiteout.io/2014/06/12/how-we-operate/
we're trying to move away from storing stuff on our servers. more on that soon.
why pbkdf2? here's why: http://www.w3.org/TR/WebCryptoAPI/#pbkdf2
Users will choose 'password'; they'll choose '12345'; they won't choose 'VPSJjNwytizY7vtGzRv208' or 'cZD2N49caaSYkDuWZMHuyiuKuk6AhA5jdC29g3moHmX' (128- and 256-bit, respectively).
> 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.
No, of course not. User-memorable passwords should only be used on devices physically controlled by the user or someone the user trusts; high-security passwords must be used on any device outside of the user's control.
It's okay to use the user's password to locally encrypt a secure key used to encrypt remote data.