

Secure PGP Sync - thefreeman
https://blog.whiteout.io/2014/07/07/secure-pgp-key-sync-a-proposal/

======
scosman
Strangely, 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.

[http://en.wikipedia.org/wiki/Key_stretching](http://en.wikipedia.org/wiki/Key_stretching)

~~~
wtbob
> 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.

~~~
scosman
Both NCF and JPAKE require a communication channel between devices. Neither
fit the bill if the goal is user friendly, accessible from anywhere, and
backup in case of loss (what they are proposing).

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.

~~~
wtbob
> Both NCF and JPAKE require a communication channel between devices.

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.

------
upperechelon
Sooo 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?

~~~
felixhammerl
wtf tls? it's not about transport. it's about us not being able to read shit
b/c you encrypted your key. i don't want your plaintext keys, so to prevent
the nsl thing from happening.

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/](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](http://www.w3.org/TR/WebCryptoAPI/#pbkdf2)

------
zokier
I 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.

~~~
wtbob
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).

~~~
zokier
So make an app that creates random passphrases. You don't need completely new
protocol for that.

~~~
kaoD
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.

