GnuPG doesn't respect key flags when decrypting
Closed, ResolvedPublic

Description

GnuPG will use keys that don't have the encryption capability for decryption. It's more of a theoretical issue, attackers definitely shouldn't be given the wiggling room to force usage of a key for decryption that is meant for certification and signing only.

This is an issue in the wild (not the first time it's come up), see: https://github.com/open-keychain/open-keychain/issues/2413

(hope this isn't a duplicate, I only did a cursory search)

Valodim created this task.Oct 27 2018, 10:24 PM
werner edited projects, added gnupg, OpenPGP, Not A Bug; removed Bug Report.Oct 29 2018, 8:47 AM
werner triaged this task as Low priority.
werner added a subscriber: werner.

I don't see a problem. If you have the private key you can and will use it. I guess your concern is an oracle?

Note that gpg will also employ revoked and expired keys for decryption. This is a real world requirement.

dkg added a subscriber: dkg.Oct 29 2018, 7:43 PM

I understand the real world requirement for decrypting messages that have been encrypted to a revoked or expired key.

In that use case, if the thing being decrypted is believed to be more recent than the revocation or expiration (which we can't really tell, because OpenPGP has no place to assert such a "freshness/age" on an encrypted blob), then a minor warning sounds reasonable.

The same *cannot* be said for a subkey that is marked specifically for certification or signing, and not for decryption.

If a user decrypts a message, a sensible tool will give them a warning if the message was decrypted using a mechanism that they did not expect to use for decryption. gpg should at least provide hooks to indicate such a warning, so that the user-facing tool can decide what to do about it.

The same *cannot* be said for a subkey that is marked specifically for certification or signing, and not for decryption.

I agree.

If a user decrypts a message, a sensible tool will give them a warning if the message was decrypted using a mechanism that they did not expect to use for decryption. gpg should at least provide hooks to indicate such a warning, so that the user-facing tool can decide what to do about it.

I disagree. A key that isn't supposed to be used for decryption by its generation parameters absolutely shouldn't be used for decryption. Not with a warning, not ever. Unlike expired and revoked keys, there is never a valid reason to do this (discounting "bug compatibility"), and oracle situations or unintended interactions between algorithms is why we are splitting up keys into signing and encryption in the first place. Ignoring that distinction on the receiving side gives an attacker completely unnecessary wiggling room.

Please reconsider.

dkg added a comment.Oct 29 2018, 8:04 PM

i agree with @Valodim that it would be better to not have a warning at all for an attempt to decrypt from secret key whose public key has never been marked as valid for encryption. A strict failure there (as with a strict failure for lack of mdc) is a better scenario than a warning. If the user controls the secret key and they decide they want to be able to decrypt with it, they should be able to mark it as decryption-capable (if that's really what they want) and retry. But this is an action only for experts.

There may be some circumstances where gpg might not know whether a particular subkey has ever been marked as encryption-capable (e.g. maybe it used to have that usage flag, and someone updated the usage flags and cleared the history of subkey binding signatures). In that case, i think it's ok for gnupg to refuse to decrypt with that subkey, even if there was some point in the past where it was known to be encryption/decryption capable, because gnupg simply doesn't know about that old usage flag marking.

I disagree, and you don't have to try to convince me, the decision is with werner. I just want to give my opinion:
Bug compatibility is nothing esoteric or bad especially for a general purpose backend tool like gnupg. Being open to accepting broken input is a good thing because it will mean that we can get people out of a "broken tool vendor lock in".

As long as there is no security concern GnuPG should be lenient in what it accepts. Having an error will mean we get yet another "ignore-usage-error" option and if it happens enough we have to handle it in the GUI like "ignore-mdc-error" making everything more complex.
There will be important data around for some people that is encrypted improperly. For them not being able to decrypt their data starting from version X will cause them either to use version X-1 or land in support because they won't know what to do.
I do not have anything against a warning.

stm added a subscriber: stm.Oct 30 2018, 9:42 PM
stm added a comment.Oct 30 2018, 9:48 PM

There is another argument for respecting the usage flags: it trims the admissible key space, if key ID in the PKESK packet is zero ('wild card') and thus all private keys have to be considered for decryption.

werner closed this task as Resolved.Nov 8 2018, 1:10 PM
werner claimed this task.

Also consider that it is possible to change the key usage flags. Thus it will never be clear whether one has a fixed or unfixed public key. I'd like to close this bug because it is currently also discussed in the IETF WG.

Fair enough. Let's wait and see what others think.