Enforcing password complexity for private keys

Werner Koch wk at gnupg.org
Fri May 3 15:44:26 CEST 2019

On Tue, 30 Apr 2019 06:55, david.milet at gmail.com said:

> We’re considering rolling out GnuPG at work for developers to sign git commits.
> How can we prevent developers from choosing a trivial password?

You can't but it is not a problem.  The passphrase is used to protect
the private key in case it ever leaks.  It is not a security measure but
a failstop mechanism.  You should use that on a laptop which can easily
get lost.  However, over there you might already use disk encryption and
thus your private key is reasonable safe.  As always it is a question of
your threat model.

On any box without easy physical access, attackers first install a
software keyboard sniffer which is a standard part of all remote attack
software.  The attacker only needs to wait until you enter the
passphrase and can then use your key and data at their own discretion.

Signing commit is a very good idea because it helps to detect the
compromised machine after an incident.  Using on-disk keys may defeats
that because an attacker could mix up the signing keys and comprimised
machines.  Whether the on-disk key has a string passphrase or none does
not matter (keyboard sniffer).

I would suggest to use a token instead because it does not compromise
the key and it is always clear which token was used to sign a commit.
Of course an attacker can also trick the developer into using that token
to sign a certain commit but that requires that the token is plugged in
and the PIN has been entered.  With tokens you may not even need to roll
out a new keys to all developers, because, they keys, themselves are not

> Is there a way for GnuPG to enforce some password complexity on the
> private keys?

If you don't want to go with a token but a strong passphrase gpg-agent
provides these options:

       --min-passphrase-len N
              Set the minimal length of a passphrase.  When entering a
              new passphrase shorter than this value a warning will be
              displayed.  Defaults to 8.

       --min-passphrase-nonalpha N
              Set the minimal number of digits or special characters
              required in a passphrase.  When entering a new passphrase
              with less than this number of digits or special characters
              a warning will be displayed.  Defaults to 1.

      --check-passphrase-pattern FILE
              Check the passphrase against the pattern given in file.
              When entering a new passphrase matching one of these
              pattern a warning will be displayed.  FILE should be an
              absolute filename.  The default is not to use any pattern

              Security note: It is known that checking a passphrase
              against a list of pattern or even against a complete
              dictionary is not very effective to enforce good
              passphrases.  Users will soon figure up ways to bypass
              such a policy.  A better policy is to educate users on
              good security behavior and optionally to run a passphrase
              cracker regularly on all users passphrases to catch the
              very simple ones.

> Is that something that a Yubikey could do? 

Use ECC keys with Yubikeys or use a Gnuk based token like the original
Gnuk token or one from another venodor like Nitrokey.  I use a GnuK
token with an ed25519 signing key to sign my commits.  IMHO, token based
4k RSA keys are too slow for regular work.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190503/95a3d3f2/attachment.sig>

More information about the Gnupg-users mailing list