FIPS-mode keygen fails to include preferences subpackets

[Ahern, William]

When libgcrypt is in FIPS mode GnuPG g10/keygen.c:keygen_set_std_prefs fails entirely in the absence of an explicit preference list, resulting in the symmetric cipher preference list and similar subpackets being omitted from the generated public key. It also effects the features subpacket. Additionally, for senders using releases before GPG 2.3.x this has the effect of causing GnuPG (in FIPS mode) to fail encryption as it defaults to 3DES in the absence of a public key preference list, regardless of runtime support.

The root cause is that 1) "S2" (i.e. 3DES) is unconditionally added to the default generated preference string causing 2) keygen_set_std_prefs to fail. keygen_set_stdprefs bails out entirely when any preference algorithm cannot be decoded using string_to_cipher_algo, even when all but one were successfully decoded. A simple fix is to use "3DES" instead of "S2" when generating the default preference list string (see top of keygen_set_std_prefs). That works because string_to_cipher_algo succeeds for "3DES" but not "S2", even in FIPS mode. The former takes a path through libgcrypt that simply maps the name to an identifier using the built-in algorithm table, whereas for "S2" a separate pathway is taken that actually queries runtime support, which will fail in FIPS mode.

Locally we're using the simple fix, but a better solution might be to 1) add "S2" conditionally, similar to how AES is treated, and 2) refactor the second half of keygen_set_std_prefs to continue processing algorithms, only failing later if none were matched in a set. I'd be happy to craft that patch if that seems like the better solution.

Regards,

- Bill