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

Using GPG to Encrypt Your Data

nas.nasa.gov

Post reply on HN
Print view View original

91–100 of 100 posts

Re: Using GPG to Encrypt Your Data

#91

Post by e12e »

nothrabannosir wrote: post #46
e12e wrote: post #26

Earlier quoted context omitted.

I've been thinking about this for a while, and the early conclusion I've come to, is that 64bits of provable random entropy in a password that's also memorable is a very high bar to clear. Imagine this, you take four word types/groups, say, substantive, verb, adverb, preposition/place. You list 128 of each - all with identified uniqly by the first two letters. You let a machine pick a word from each column at random.…

Why truncate the words down to the first two letters? Are you reinventing xkcd 936?

For ease of typing. Typically you have to enter passwords verbatim - typically passwords need to be entered without error, blindly. 16 characters is easier to get right that 60.

And while it might feel good to pretend full words add entropy, if you assume the attacker knows your system - it really doesn't (hence "guaranteed" entropy).

As for diceware, I don't find those passwords easy to remember - especially past 60 bits of entropy. But use what works for you.

Re: Using GPG to Encrypt Your Data

#92

Post by e12e »

shawn-furyan wrote: post #62
e12e wrote: post #26

Earlier quoted context omitted.

I've been thinking about this for a while, and the early conclusion I've come to, is that 64bits of provable random entropy in a password that's also memorable is a very high bar to clear. Imagine this, you take four word types/groups, say, substantive, verb, adverb, preposition/place. You list 128 of each - all with identified uniqly by the first two letters. You let a machine pick a word from each column at random.…

Rather than rolling your own password system, I would recommend diceware.com for strong passwords (including master passwords) that you can memorize (I am bad at memorization, and have memorized 129 bit passwords this way, and 64 bit passwords are kind of a breeze to memorize). For the long tail of passwords that you shouldn't be memorizing in the first place, a password manager with a good configurable password gene…

The reason I've been thinking about this, is that I'm not happy with diceware. Five words (64 bits of "guaranteed" entropy) is around 20 characters - and I'm not sure if diceware looses some entropy if you omit spaces (eg: "at hat" and "a that" both become "athat").

My main takeaway looking at the problem, is that 64 bits is a lot to encode in ~26 letters and maybe 10 digits - in a way that is easy to remember, easy to type, easy to read (if eg: given a printed initial password, read/hear (sharing over the phone/double as a way to read out a hash/shared key etc).

My main issue with diceware is the large number of words; almost touching on typical active vocabulary of even native speakers - never mind if your users speak little or no English. One benefit of the system above is that as long as you can come up with four/five sets of 128 words that don't collide among themselves in the groups of 128 - you can adapt the system to any alphabet and preserve any guarantees of entropy. Making a diceware wordlists is a huge undertaking by comparison. (But the benefit is that people have already done this for many languages).

Re: Using GPG to Encrypt Your Data

#93

Post by jph »

vesinisa wrote: post #22
jph wrote: post #8

For GPG symmetric encryption, the kind the article describes, here are the best options I've found for my typical case: gpg --symmetric \ --cipher-algo aes256 \ --digest-algo sha256 \ --cert-digest-algo sha256 \ --compress-algo none -z 0 \ --quiet --no-greeting \ --no-use-agent "$@" I keep this command here: https://github.com/SixArm/gpg-encrypt The options are chosen to balance tradeoffs of convenience, strength, an…

You can also explore the --s2k-* options to add a level of difficulty to hashing the password to protect against brute-forcing. E.g. --s2k-mode 3 --s2k-digest-algo sha512 --s2k-count 1000000 Default is to use salt + one round of SHA1, which is relatively weak.

Thank you. I added your options to the repo and thanked you there too.

Re: Using GPG to Encrypt Your Data

#94

Post by rakoo »

throwawayish wrote: post #24
rakoo wrote: post #17

Earlier quoted context omitted.

Because the paragraph on key generation and management would be 3 times as long as the entire article in its current form ? Asymmetric encryption solves the problem of transmitting the password safely ("solve" is a rather optimistic word, maybe "delegates" is more appropriate); if you can safely transfer passwords from point to point, then using symmetric encryption is far easier.

Asymmetric cryptography transforms key distribution problems into key management problems. Which is just a different problem, not necessarily an easier one, like you say.

> Asymmetric cryptography transforms key distribution problems into key management problems.

That's a very nice way to put it, I'm going to reuse that !

Re: Using GPG to Encrypt Your Data

#95

Post by nothrabannosir »

e12e wrote: post #91
nothrabannosir wrote: post #46

Earlier quoted context omitted.

Why truncate the words down to the first two letters? Are you reinventing xkcd 936?

For ease of typing. Typically you have to enter passwords verbatim - typically passwords need to be entered without error, blindly. 16 characters is easier to get right that 60. And while it might feel good to pretend full words add entropy, if you assume the attacker knows your system - it really doesn't (hence "guaranteed" entropy). As for diceware, I don't find those passwords easy to remember - especially past 60…

> And while it might feel good to pretend full words add entropy, if you assume the attacker knows your system - it really doesn't (hence "guaranteed" entropy).

It does: munroe's proposed scheme operates on the assumption the attacker knows it. The 11 bits of entropy refer to a dictionary of 2K words to choose from. The reason to type full ones is you're not hamstrung by the "no common prefix" limitation, which allows larger (and easier to remember) dictionaries.

Also, we're talking theory. Typing them blindly is an artificial implementation limitation imposed on us by bad software. Just like "you need at least one digit", "maximum length 16", &c. If you're going to consider those, that's fine, but then you're not talking about actual password theory anymore--you're just discussing how to cope with bad platforms.

Case in point: many good PW forms (OS logins, &c) have no such limitations, and offer a "view password while typing" option.

Re: Using GPG to Encrypt Your Data

#96

Post by e12e »

nothrabannosir wrote: post #95
e12e wrote: post #91

Earlier quoted context omitted.

For ease of typing. Typically you have to enter passwords verbatim - typically passwords need to be entered without error, blindly. 16 characters is easier to get right that 60. And while it might feel good to pretend full words add entropy, if you assume the attacker knows your system - it really doesn't (hence "guaranteed" entropy). As for diceware, I don't find those passwords easy to remember - especially past 60…

> And while it might feel good to pretend full words add entropy, if you assume the attacker knows your system - it really doesn't (hence "guaranteed" entropy). It does: munroe's proposed scheme operates on the assumption the attacker knows it. The 11 bits of entropy refer to a dictionary of 2K words to choose from. The reason to type full ones is you're not hamstrung by the "no common prefix" limitation, which allow…

But there's a reason for hiding password input: [ed: making shoulder surfing a little harder]. Or unlocking a computer that's projecting to an audience. [ed: see also citizenfour where Snowden uses a blanket when typing in a pass phrase].

This is indeed not about password "theory", because experience shows that actual system (in)security happens where computer systems and users interact.

Using a common subset of keyboard layouts for different languages (limiting the character set), being workable on touch screens, are important for security. And using passwords at all is working around "bad platforms".

> The 11 bits of entropy refer to a dictionary of 2K words to choose from. The reason to type full ones is you're not hamstrung by the "no common prefix" limitation, which allows larger (and easier to remember) dictionaries.

From playing with this, I'm not convinced the tradeoff of using a big dictionary whose that cannot be enumerated by a short unique prefix (to reduce length) really adds that much - just like increasing the character set beyond 26/36 helps all that much - because you only gain a bit for every doubling in size.

My idea is for the mnemonic to form an actual "story" (in a secure way) - in the hope that it's easier to remember : "boy flies angrily away" than "correct horse battery stapple".

A) that may be wrong

B) You still need too many words in order to encode a "high enough" entropy

Re: Using GPG to Encrypt Your Data

#97

Post by e12e »

nothrabannosir wrote: post #95
e12e wrote: post #91

Earlier quoted context omitted.

For ease of typing. Typically you have to enter passwords verbatim - typically passwords need to be entered without error, blindly. 16 characters is easier to get right that 60. And while it might feel good to pretend full words add entropy, if you assume the attacker knows your system - it really doesn't (hence "guaranteed" entropy). As for diceware, I don't find those passwords easy to remember - especially past 60…

> And while it might feel good to pretend full words add entropy, if you assume the attacker knows your system - it really doesn't (hence "guaranteed" entropy). It does: munroe's proposed scheme operates on the assumption the attacker knows it. The 11 bits of entropy refer to a dictionary of 2K words to choose from. The reason to type full ones is you're not hamstrung by the "no common prefix" limitation, which allow…

> The 11 bits of entropy refer to a dictionary of 2K words to choose from. The reason to type full ones is you're not hamstrung by the "no common prefix" limitation, which allows larger (and easier to remember) dictionaries.

Another note on this - assume an average word length of 5 - that's 11/5 or 2.5 bits per character typed (again, assuming the wordlist doesn't loose some bits for "double coding" like "at hat/a that").

At 7 bits per word - of which two characters are enough, we type 7/2 or 3.5 bits per character.

Conversely, we only memorize 7 bits per word vs 11 bits.

Re: Using GPG to Encrypt Your Data

#99

Post by terrywang »

sorenjan wrote: post #79
veeti wrote: post #51

Earlier quoted context omitted.

Is there anything like this that doesn't leak the folder structure in plaintext? Manually obfuscating site names would be very tedious.

How about KeePass?

I personally think it's a pretty good password manager (like all others, database sync is a problem for users to solve). I had been using its Linux port -> keepassx (also available for macOS - yes NOT Mac OS X any more...)

Features: http://keepass.info/features.html

I switched to pass / qtpass (cross-platform Qt frond-end for pass) after seeing it on hacker news (or somewhere else like Twitter) because it uses GnuPG + git (simple and I am capable of both in CLI). Last but not least, pass provides migration scripts from keepass/keepassx (and a lot more... - feel like I had to migrate ;-)

Re: Using GPG to Encrypt Your Data

#100

Post by acqq »

analogist wrote: post #76
tptacek wrote: post #44

Earlier quoted context omitted.

That's not at all true. Simple symmetric offline encryption of files is one of the few crypto operations that is easy to get right. The GPG1 defaults aren't great, but they aren't going to get your files compromised. And with the command line options presented upthread, you have the passphrase problem either way.

The symmetric algorithm aside, if we just look at the key derivation, the --s2k* parameters go up to 65011712 rounds of SHA512. If you maxed out the --s2k* settings, its difference from the 1.4.12 default of 65536 rounds of SHA1 is not staggering, but not trivial either: 10 extra bits from the additional rounds and an additional 3-4 bits from straight SHA1 to straight SHA512, on modern GPUs ( https://gist.github.com/…

Thanks a lot for the link, it's a wonderful overview of the password cracking capabilities of the modern GPUs.
Post reply on HN