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

61–70 of 100 posts

Re: Using GPG to Encrypt Your Data

#61

Post by acqq »

tptacek wrote: post #52
acqq wrote: post #47

Earlier quoted context omitted.

> they aren't going to get your files compromised. The default encryption is CAST5 which is a 64-bit block size cipher (even if it is confusingly called "CAST-128"). The default password derivation is using SHA1. That's the reason people change the defaults. If you like them, you're of course free to use them or recommend them to your clients. Good luck. Of course I'd also like to read your explanation how you can co…

Neither of those two things matter very much for file encryption. The short block size, for instance, is a very big deal with online encryption, but not a dealbreaker for offline encryption.

> The short block size ... not a dealbreaker for offline encryption.

Which scenarios do you assume to be valid for offline encryption which don't make short block sizes problematic?

Why is poor password handling not a problem under these scenarios?

Re: Using GPG to Encrypt Your Data

#62

Post by shawn-furyan »

e12e wrote: post #26
parfe wrote: post #2

>We suggest that you include five words of 5-10 letters in size, chosen at random, with spaces, special characters, and/or numbers embedded into words. >You need to be able to recall the passphrase that was used to encrypt the file. Why bother writing security guidelines which are impossible for a human to follow? edit: Try recalling any passphrases generated by the command below, and that's before the random sprinkl…

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 generator is invaluable. I use Lastpass (I like the breadth of it's platform support: all major consumer OSes, all major mobile OSes, extensions for all major browsers). Alternatively, lot of people recommend 1password.

Diceware has better guarantees, but the password managers are usually much more convenient[1]. I weigh these costs and benefits when choosing which way to go for a particular use case.

[1] With the significant exception of passwords that will regularly have to be typed out on mobile, since diceware passwords are much more virtual keyboard friendly than random character generated passwords. This is partly because you can typically keep the entire thing in your head, not having to reference your password manager multiple times, and partly because they don't rely on special characters for their entropy, so can be typed out on the primary keyboard without switching to numeral or special character keyboards.

Re: Using GPG to Encrypt Your Data

#63

Post by dvko »

rdslw wrote: post #43

If we're talking about GPG, please pay attention to https://www.passwordstore.org/ which is really cool, open source password manager built on GPG.

I switched from OSX to Linux a few months ago and had to find an alternative for 1Password. Pass has been great, I love its simplicity.

Not having a browser add-on to retrieve passwords was feeling like a step back in terms of convenience though. That's why I built & open sourced browserpass [1], a browser extension for Pass.

It uses Native Host Messaging to securely retrieve passwords, so no crazy port listening as some other open-sourced add-ons do (which is a terribly bad idea).

[1] https://github.com/dannyvankooten/browserpass

Re: Using GPG to Encrypt Your Data

#64

Post by dvko »

veeti wrote: post #51
rdslw wrote: post #43

If we're talking about GPG, please pay attention to https://www.passwordstore.org/ which is really cool, open source password manager built on GPG.

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

Masterkey [1] might be interesting for you. It's using NACL and Go and stores everything in a single encrypted file.

1: https://github.com/johnathanhowell/masterkey

Re: Using GPG to Encrypt Your Data

#65

Post by jwilk »

brotherjerky wrote: post #57
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…

Does `-no-use-agent` work? I see this in man: --no-use-agent This is dummy option. gpg always requires the agent.

Contemporary versions of GnuPG (>= 2.1 IIRC) always use gpg-agent, and this option does nothing except producing a warning:

  gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect

Re: Using GPG to Encrypt Your Data

#66

Post by teddyh »

acqq wrote: post #36
throwawayish wrote: post #21

Earlier quoted context omitted.

The defaults he has chosen hints at a distro that ships GPG v1 / classic, which has stranger defaults than GPG v2. IIRC the default ciphers are CAST5, (very slow) compression is on by default, hashes are RIPEMD I believe and so on

Exactly. The defaults of GPG 1, the one which can be used as a single not-too-big binary, seem to be poor. GPG 2 has better defaults, but it grew to include the kitchen sink and have a lot of moving parts, and I'd still prefer to have a good smaller program that does only a few things but do them good. My ideal would be a small executable with as little dependencies as possible.

Like gpgv or symcryptrun, maybe?

https://gnupg.org/documentation/manuals/gnupg/gpgv.html#gpgv

https://gnupg.org/documentation/manuals/gnupg/symcryptrun.ht...

Re: Using GPG to Encrypt Your Data

#67

Post by tptacek »

acqq wrote: post #61
tptacek wrote: post #52

Earlier quoted context omitted.

Neither of those two things matter very much for file encryption. The short block size, for instance, is a very big deal with online encryption, but not a dealbreaker for offline encryption.

> The short block size ... not a dealbreaker for offline encryption. Which scenarios do you assume to be valid for offline encryption which don't make short block sizes problematic? Why is poor password handling not a problem under these scenarios?

Neither gpg2 nor gpg1's defaults make short passwords safe; really, though, with a single targeted password, your passphrase needs to be extreme no matter what settings you use.

I'm not sure why an 8 byte block would materially impact file encryption. The kinds of attacks where short blocks come in handy are all online, CCA-style attacks. You might worry about things like CTR counter block sizes, but, again, not an issue for GPG1's defaults.

I'm not saying they're good settings. And: in particular, if you used them to encrypt something like session cookies, you could have serious vulnerabilities. But like I said: it's easy to encrypt files, and some things that are survivable for files aren't for other applications.

Re: Using GPG to Encrypt Your Data

#68

Post by teddyh »

rdslw wrote: post #41
woliveirajr wrote: post #40

There's the [2015] which should be included.

No it shouldnt. It imposes (false) perception that anything not from today is old/not fresh/known/bad knowledge. It is not true. This hunt for dates in titles on HN is bad and it's awitch hunt these days. Disclaimer: I'm not an author nor submitter.

This is “Hacker News”.

Re: Using GPG to Encrypt Your Data

#69

Post by grzm »

rdslw wrote: post #41
woliveirajr wrote: post #40

There's the [2015] which should be included.

No it shouldnt. It imposes (false) perception that anything not from today is old/not fresh/known/bad knowledge. It is not true. This hunt for dates in titles on HN is bad and it's awitch hunt these days. Disclaimer: I'm not an author nor submitter.

Adding the year does nothing other than let people know when it was published and gives it some context. You're reading too much into this. The practice goes back at least 2½ years.

Re: Using GPG to Encrypt Your Data

#70

Post by digler999 »

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…

do you know if gpg embeds a header in the cyphertext ? It always bothered me that openssl (for symmetric aes) puts "Salted_" as the first 7 bytes in every encrypted file, because it seems to nullify the "plausible deniability" defense and the "cyphertext should be indistinguishable from random data" tenet. Sure, having "Salted" doesn't prove that AES was run on the following bytes, but there's no plausible explanation as to what other program would do such a thing.
Post reply on HN