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.

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)

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

The GPG1 defaults are definitely not great, but I'm not sure they have much practical impact for this use case.

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 are (found experimentally):

--s2k-mode = 3

--s2k-digest-algo = SHA1 (supports MD5, RIPEMD-160, SHA2s too)

--s2k-count = 65536 (supports from 1024 to 65011712)

--s2k-cipher-algo = CAST5 (supports 3DES, CAST5, Blofish, AES, Twofish, Camellia too)"

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.

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

> 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 consider 64-bits "secure enough" today (or for what you consider them secure enough). Also your estimate of how expensive would be to brute force shorter passwords for the traditionally small number of default rounds of SHA1. Thanks.

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.

My main gripe with them is, apart from being a bit obscure, is that they're bog-slow. They give me something like two dozen MB/s encryption/decryption speed, on a machine that can do AEAD at 2.5-4 GB/s (AES-GCM or Chapoly). A large part of that is the compression (zlib-ish I think), though.

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.

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

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

Nice script, though I must note that it will only work on Linux. Tried it on macOS, but there is no `/dev/shm`.

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.

Thanks, I've added your info to the README and a credit to you.

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?

The defaults are acceptable, and will produce a symmetrically encrypted file that can be quickly decrypted on even low-powered ARM cores in a reasonable amount of time.

These suggestions strike a different balance between protection and speed.

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

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

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

I'll remove it now. It was useful to have (for me) for GPG version 1 when I connected to machines via SSH and didn't want a GPG agent pop up UI, and didn't have an easy way to change the GPG agent settings.

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

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

I disagree. set -eu should be at the top of every bash script.

This is the classic braceless if-guard mistake; leave it out today because you don't need it, forget, add something tomorrow and it breaks.

You can over-rely on "set -e" however:

  #!/usr/bin/env bash
  set -e
  fail() { false ; echo hello; }
  if ! fail; then :; fi

That outputs "hello" and exits with 0.

Not the author of the code, but personally, I don't see any downside to putting "set -eu" at the beginning of every script I write. These should be defaults.

You're correct. I use -euf as a default for new scripts, until someone asks for relaxing these. I'll remove the -f now because you're right, globbing can be useful.

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.

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