Use better key stretching

[lukechilds]

Default key stretching is ok but this is stronger.

gpg \
--symmetric \
--cipher-algo aes256 \
--digest-algo sha256 \
--cert-digest-algo sha256 \
--compress-algo none -z 0 \
--s2k-mode 3 \
--s2k-digest-algo sha256 \
--force-mdc \
--quiet --no-greeting

Source: https://github.com/SixArm/gpg-encrypt

Thanks @joelparkerhenderson!

[joelparkerhenderson]

You're welcome. Glad you find this useful.

I see you're writing a significant shell script that also includes security; you may find some useful ideas in the team's shell style guide: http://github.com/sixarm/sixarm_shell_style_guide

[lukechilds]

Thanks, that looks like a great resource 🍻

[lukechilds]

@joelparkerhenderson Just out of interest, are you aware of a way I can bypass the password cache for a single command?

The users should be prompted for the password every time the try to decrypt, it should never be cached and automatically decrypt.

I currently have a configurable CHEST_CLEAR_PASSWORD_CACHE="true" option to run gpgconf --reload gpg-agent after the user enters the password so it isn't cached.

This is obviously not ideal because it completely reloads the gpg agent.

--no-use-agent sounded like it would do what I want but it just gives me:

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

[joelparkerhenderson]

To the best of my knowledge, a gpg program cannot bypass the agent in the way you want.

I looked for quite a while a year ago, and it seemed to me that the gpg command was deliberately aiming more toward being akin to an account-wide keyring and less toward a single-use key.

For example the GPG command line option --no-use-agent was phased out and replaced by the broader pinentry concept.

My personal opinion is that for some of my purposes, i.e. for simple symmetric encryption of files that we send to our customers, the gpg agent cache effect makes the UI/UIX problematic and too confusing for some novices.

Like you, I looked at restarting the agent each time, but found that the approach didn't sit well with some experts, and sometimes interfered with other legitimate uses of gpg that ran on the same accounts, such as secure email programs and git signing.

The cache issue is what made me look for alternatives, and I chose openssl. The openssl code has had some significant security bugs yet seems solid enough to me for the symmetric encryption areas.

The exact code we use now is https://github.com/sixarm/openssl-encrypt

[lukechilds]

and sometimes interfered with other legitimate uses of gpg that ran on the same accounts, such as secure email programs and git signing.

I knew it might be annoying for people who have other keys they want cached but hadn't even considered breaking software that depended on it :/

The cache issue is what made me look for alternatives, and I chose openssl.

I looked at OpenSSL originally but from what I read the KDF was considerably weaker which was why I went with GPG. Is that still the case?

[joelparkerhenderson]

I haven't looked at the KDF specifically. What I found last year was a general opinion that the OpenSSL code could benefit from some more people helping, including developers and also reviewers.

I never found a good solution to few of my needs: 1) always doing a password prompt on the console, 2) running reliably in a macOS terminal after I su to a different user, without needing pinentry adjustments, 3) encrypting multiple files in one command, such as a hundreds of password files for automated code deployments by a deploy-only user account.

[lukechilds]

As far as I was aware it just does a SHA-256 hash of the input to use as the encryption key. It expects input to be sufficiently secure, passing a user supplied password in directly would not be very strong to use directly as an encryption key and would be highly susceptible to brute force force attacks.

There may be options to change that though, I'm not sure. This is all off the top of my head from some reading I did over a year ago so take it with a grain of salt.

Oh well, thanks for taking the time to answer my questions, appreciate it. I will probably just stick with gpgconf --reload gpg-agent. It works fine for me and it's easily disabled via an ENV option if it causes issues for other users.

[joelparkerhenderson]

You're welcome. If you happen to find a better solution, whenever in the future, can you do me a favor and post it here? I would like to try it. Thank you!