Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Secure PGP Sync

blog.whiteout.io

Post reply on HN
Print view View original

11–15 of 15 posts

Re: Secure PGP Sync

#11

Post by rakoo »

zokier wrote: post #6
wtbob wrote: post #5

Earlier 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.

A random passphrase you'll then need to enter on all your devices. Do you really think people will bother with that ?

Re: Secure PGP Sync

#12

Post by scosman »

wtbob wrote: post #4
scosman wrote: post #3

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 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 JP…

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.

Re: Secure PGP Sync

#13

Post by felixhammerl »

upperechelon wrote: post #9

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?

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/

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

Re: Secure PGP Sync

#14

Post by wtbob »

scosman wrote: post #12
wtbob wrote: post #4

Earlier quoted context omitted.

> 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 JP…

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 us…

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

Re: Secure PGP Sync

#15

Post by wtbob »

upperechelon wrote: post #10
wtbob wrote: post #5

Earlier 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).

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

> Yeah but no user is ever going to be able to remember either of those passwords,

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.

Post reply on HN