After having tea with a friend, I sent her an email telling her to feel free to mention it to others if she was so inclined -- and GnuPG seems to have selected the wrong algorithm. I'm including the email and relevant data here.
===== Subject: Oh, and-- From: "Robert J. Hansen" <[email protected]> Date: 1/17/15, 5:34 PM To: Raven Alder <[email protected]> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If you feel like mentioning our tea on LJ, please, feel free. Use your own best judgment as to what things you relate to others. :) -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJUuuNaAAoJEERqRG+BDbXQWlQH/0VZAfeBmrmwiMqkWwFxhNe5 5hvUjJbXIufQBaz/2DsC/yyPZIWe5DAtuwa4sbKCyvuSkzWJ0gJheqwADgOak1GA 1lOiIzI7xru1Qn6ZYY9qHNpvFW9/OGIkoLf3dZVO7NdW3Uvg7aE9RMah+LF+vCtM xs3TLQlXMAt4aDliZqyihilxUw7jGEUguVMeEBOP9Nq2s6k2W0oxKVn1i2tHW3u6 knCxCMeWspF1Fs7gnvL6zov2PHPb6DF7K7eYqHlLJo894xQu+NwzCGgGSCu9gmJ8 O8+paerf0fLKtX9FxYSerfkP7eS4dOrF/XHwL6N1WlSghlh4vJMQnWGUFXoostU= =rJ25 -----END PGP SIGNATURE----- ===== Note the SHA-1 hash selection. This seems ... very odd. Checking her key I see: quorra:~ rjh$ gpg --edit-key Raven pub dsa1024/3D7489C0 created: 2002-02-21 expires: never usage: SC trust: unknown validity: unknown sub elg2048/5DD7F638 created: 2002-02-21 expires: never usage: E [ unknown] (1). Raven Alder <[email protected]> [ unknown] (2) Raven (Key #2) <[email protected]> [ unknown] (3) Raven Alder <[email protected]> gpg> showpref [ unknown] (1). Raven Alder <[email protected]> Cipher: AES256, AES192, AES, CAST5, 3DES Digest: SHA1, RIPEMD160 Compression: ZLIB, ZIP, Uncompressed Features: MDC, Keyserver no-modify [ unknown] (2) Raven (Key #2) <[email protected]> Cipher: AES, TWOFISH, CAST5, BLOWFISH, 3DES Digest: RIPEMD160, SHA1 Compression: ZLIB, ZIP, Uncompressed Features: Keyserver no-modify [ unknown] (3) Raven Alder <[email protected]> Cipher: AES256, AES192, AES, CAST5, 3DES Digest: SHA1, RIPEMD160 Compression: ZLIB, ZIP, Uncompressed Features: MDC, Keyserver no-modify ... okay, so each and every user ID lists RIPEMD160 as a hash algorithm; that's good. Now let's look at my preferred algorithms. quorra:~ rjh$ grep default-pref .gnupg/gpg.conf default-preference-list SHA256 RIPEMD160 AES256 CAMELLIA256 TWOFISH 3DES ... As I understand the way algorithms are selected, GnuPG uses the most-preferred algorithm in my list that is also present in the recipient's capability set. Since SHA-1 implicitly follows after SHA256 and RIPEMD160, it has the lowest priority. By my understanding, GnuPG should start by trying SHA256 and discovering Raven doesn't advertise that as a capability. It should then try RIPEMD160 and see Raven advertises that, and thus it should use RIPEMD160. Instead, it went to SHA-1. This seems like a bug in the algorithm selection code. Note: my certificate's primary signing key is DSA2048, which would seem to require SHA224 or longer. However, in order to be able to sign messages for people who don't support anything other than SHA-1 or RIPEMD160 I added an RSA2048 signing subkey a couple of years ago. It only gets used when DSA2048 is unavailable, such as here. So please, don't panic when you notice it was signed with a key other than my primary. :)
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
