Using GPG to Encrypt Your Data

[jph]

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, and portability.

[vesinisa]

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.

[tptacek]

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)

[larose]

I did something similar to gpg-encrypt: https://github.com/larose/eef/

It's a wrapper for gpg to edit encrypted files.

[twr]

Here's an alternative to wrapping GPG, using .gnupg/gpg.conf:

  personal-cipher-preferences AES256 AES
  personal-digest-preferences SHA256 SHA512
  personal-compress-preferences Uncompressed
  default-preference-list SHA256 SHA512 AES256 AES Uncompressed
  
  cert-digest-algo SHA256
  
  s2k-cipher-algo AES256
  s2k-digest-algo SHA256
  s2k-mode 3
  s2k-count 65011712
  
  disable-cipher-algo 3DES
  weak-digest SHA1
  force-mdc

Note that these options impact compatibility with other GPG/PGP clients.

[api]

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?

[brotherjerky]

Does `-no-use-agent` work? I see this in man:

       --no-use-agent
              This is dummy option. gpg always requires the agent.

[txutxu]

Regarding the code...

    set -euf
    onecmd --args "$@"

The set -u is unneeded, as there are no code variables involved.

The set -e is not needed, as there is only one command, and the script will return the exit status of such command. Always. And will exit after that command. Always.

The set -f, will disable globbing, which I'm not sure it's what you want, when using a simple wrapper passing "$@" as filenames to gpg...

[digler999]

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.

[rdslw]

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.

[dvko]

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

[veeti]

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

[openplatypus]

And QtPass with it. https://qtpass.org/

[ballpointcarrot]

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

[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

[agumonkey]

My paranoid self wanted to replace rm with shred.

[parfe]

>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 sprinkling of punctuation.

    grep -E "^[a-z]{5,10}$" /usr/share/dict/words | shuf -n5 | tr '\n' ' '

[e12e]

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. The phrase is your mnemonic key, the password (to type in) is the first two letters of each word, concatenated.

If you want to appease password strength checks, capitalise the first letter, and end the input with a period.

So: "girl runs happily up", becomes "giruhaup" (or, with equivalent entropy, but satisfying "at least three symbol groups": "Giruhaup.").

Now, that's then 4 picks out of 128 words, or an encoding of 4 times 7 bits (2^7=128) - 28 bits. You'd need three such passwords concatenated to break past 64 bits of entropy. And you'd have to type in 24 letters. That's pretty hard to type in blind without a typo.

You might be able to use lists of 256 words - but it'd make it a bit more difficult to make the wordlists (because words should be identified by the first two characters) - and you'd still need two "phrases" and type in 16 characters.

Adding random numbers, symbols or capitalization is probably not worth the challenge they add in remembering where they go, for the single/few bits of entropy they add.

And I'm still not convinced 16 characters is short enough to be usable for "most people".

[HappyTypist]

Is it really impossible for a human to follow?

"Shiny C0rrect H0rse Battery Staple!"

[0xffff2]

I do this... I have 3-4 randomly generated passwords memorized. One for each "important" account (e.g. email, banking).

[necessity]

s/human/me

[oripel]

Key stretching is critical for password-based encryption, and gpg's s2k options are vulnerable to GPU acceleration. Command-line tools to encrypt with bcrypt/scrypt are common and may be a better option.

[kondbg]

Is there a benefit in using symmetric encryption vs specifying yourself as a recipient?

[SeaDude]

The HECC site here is one of the best support sites i've ever seen. Very logically laid out KB, news, ask a question, etc.

thanks for the link

[woliveirajr]

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

[rdslw]

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.

[discreditable]

Why would they not use asymmetric encryption?

[rakoo]

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.

[gcp]

...and why encrypt stuff transferred with scp?

[jph]

Symmetric is easier to teach to people, especially large groups of people doing tech training.

[brockers]

GPG, of course, allows you to use asymmetric crypto and currently supports RSA, RSA-E, RSA-S, ELG-E, and DSA algorithms for that purpose.

But for bulk data encrypting good symmetric (AES, CAST5, etc.) is both more secure and significantly faster.