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

71–80 of 100 posts

Re: Using GPG to Encrypt Your Data

#71

Post by tptacek »

api wrote: post #54
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…

This illustrates what's wrong with GPG: it's too hard to use. Why so many arguments for a common task? Why aren't the defaults acceptable?

You can safely just use "gpg -c" to encrypt files.

Re: Using GPG to Encrypt Your Data

#72

Post by grzm »

teddyh wrote: post #68
rdslw wrote: post #41

Earlier quoted context omitted.

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

The "News" is a bit of a misnomer. Any submission that "gratifies intellectual curiosity" is on-topic, regardless of age.

Re: Using GPG to Encrypt Your Data

#73

Post by viraptor »

digler999 wrote: post #70
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 explanatio…

> do you know if gpg embeds a header in the cyphertext ?

    $ file /tmp/something.gpg 
    /tmp/something.gpg: GPG symmetrically encrypted data (AES cipher)
It has to, otherwise you'd have to know and use exactly the same options when decrypting. You could always strip it manually if you don't want this...

Re: Using GPG to Encrypt Your Data

#74

Post by ballpointcarrot »

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.

In addition, there's a Android client for it as well, so you can take your passwords on the go:

https://play.google.com/store/apps/details?id=com.zeapo.pwds...

Re: Using GPG to Encrypt Your Data

#76

Post by analogist »

tptacek wrote: post #44
acqq wrote: post #42

Earlier quoted context omitted.

What is "this use case" for you? The topic of the article is symmetric encryption, and whoever uses the defaults has much more chance to produce the files which could be compromised. it is a huge practical impact for me. Even when not using the defaults, the passphrases have to be really, really long to keep the content safe. http://security.stackexchange.com/questions/15632/what-is-pu... "In GnuPG 1.4.12 defaults ar…

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/epixoip/a83d38f412b4737e99bbef804a27...).

An additional 13 bits of safety margin basically gives you an extra Diceware word (log2(7776)), which, I agree, isn't a magical solution at all, but would to me cross the threshold of "it has some actual impact".

Of course, having much better usability for the average user, or just breaking OpenPGP compatibility so there are clean modern robust constructions like NaCl/libsodium running underneath are way better ways to get at good security margins, but here we are.

Re: Using GPG to Encrypt Your Data

#77

Post by RJIb8RBYxzAMX9u »

Unless compatibility with gpg is a requirement, I think scrypt[0] is a much simpler tool for file encryption. The utility is meant to showcase the KDF of the same name. It's very simple and has virtually no parameters. So:

  $ xz -k elrond_minutes.txt
  $ scrypt enc elrond_minutes.txt.xz elrond_minutes.txt.xz.enc
  $ signify -S \
      -s vilya.key \
      -m elrond_minutes.txt.xz.enc \
      -x elrond_minutes.txt.xz.enc.sig
  $ rm elrond_minutes.txt{,.xz}
Signing the final output is probably extraneous; I think scrypt uses a HMAC. This involves invoking multiple tools, but since each tool only does one thing it's much easier to reason about, and I prefer this over using an omnibus tool like gpg.

[0] https://github.com/Tarsnap/scrypt

Re: Using GPG to Encrypt Your Data

#78

Post by agumonkey »

RJIb8RBYxzAMX9u wrote: post #77

Unless compatibility with gpg is a requirement, I think scrypt[0] is a much simpler tool for file encryption. The utility is meant to showcase the KDF of the same name. It's very simple and has virtually no parameters. So: $ xz -k elrond_minutes.txt $ scrypt enc elrond_minutes.txt.xz elrond_minutes.txt.xz.enc $ signify -S \ -s vilya.key \ -m elrond_minutes.txt.xz.enc \ -x elrond_minutes.txt.xz.enc.sig $ rm elrond_min…

My paranoid self wanted to replace rm with shred.

Re: Using GPG to Encrypt Your Data

#79

Post by sorenjan »

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.

How about KeePass?

Re: Using GPG to Encrypt Your Data

#80

Post by mayailurus »

tptacek wrote: post #20
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…

What is this getting you that a simple 'gpg -c' isn't? (I'm asking seriously; I don't have a strong opinion about GPG command line arguments)

One thing that that gives you is the MDC packet, which isn't enabled by default in gpg classic. (Hence the parade of "message was not integrity protected" warnings.)

It can be requested directly via '--force-mdc', but, as long as you're tweaking the configuration, you might as well boost everything up to the full "Grovergeddon" settings.

Post reply on HN