On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]

David Shaw dshaw at jabberwocky.com
Sat Jun 28 15:22:17 CEST 2014

On Jun 28, 2014, at 5:20 AM, MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote:

> Hash: SHA512
> Hi
> On Friday 27 June 2014 at 11:35:00 PM, in
> <mid:A2F8DBA9-1DA7-47A6-BC79-CFAEA3B02BC3 at jabberwocky.com>, David Shaw
> wrote:
>> Incidentally, since subkeys have come up in this
>> thread, I seem to recall a few strange bugs with 8.x
>> (8.0? 8.1?) that make it difficult to use if the key
>> you are encrypting to has a signing subkey.  8.x didn't
>> always handle signing subkeys properly, so could end up
>> failing to encrypt (it wasn't 100% of the time - it
>> depended on which subkey was dated first).  If anyone
>> is curious, I'll dig out my notes for this.  I
>> submitted the bug to PGP, and I know it was fixed in a
>> later version.
> My recollection is that PGP 8.x would always try to encrypt to the
> newest subkey, and encryption would fail if the newest was a signing
> subkey. I had 8.0.3 and 8.1; if memory serves, both had this issue -
> signing subkeys were fairly new at the time.

Yes, that was it.  It got particularly strange when someone was using an RSA signing subkey or auth key (as they would do if they had a smartcard).  In that case, the PGP encryption would actually succeed (after all, RSA is capable of it, despite what the key flags instructed for use) but the GnuPG recipient would be unable to decrypt as from their perspective, that key was sign or auth only.

I put a limited workaround in GnuPG at the time - that's why the encryption key is always written to the card after the auth key (so the encryption key would always be the "newest".  Of course, that didn't handle existing keys.  The real fix was needed in PGP, and it was fixed.


More information about the Gnupg-users mailing list