Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crypt::OpenPGP does not use encryption subkey, ignores key usage #9

maertsen opened this issue Jul 9, 2013 · 7 comments


Copy link

maertsen commented Jul 9, 2013

Crypt::OpenPGP does not use an encryption subkey if available and uses the primary (sign-only) key for encryption. This is unfortunate for those of us using the subkey mechanism to store the primary key offline; a Crypt::OpenPGP will consequently encrypt to a private key not available.
(And decrypting with a signing key would be unwise in any case)

I found out about this while trying to use the secure e-mail mechanism of Bugzilla (Mozilla's own instance). An independent bugreport was filed earlier [1]. A workaround consists of manually splitting public keys, but this is tedious and error-prone.

Is there any chance support for key usage could be implemented?


Copy link

Specifically, I'd expected Crypt::OpenPGP to encrypt to the non-revoked encryption subkey whose expiry time is the furthest in the future.

Copy link

Is there any chance support for key usage could be implemented?

Patches are very welcome at the very least!

Copy link

For what it's worth, I think this bug stems from these lines:

my @valid = $pkg->all_props;
my %valid = map { $_ => 1 } @valid;

which map the key usage to the whether or not the key should be used according to subroutines like can_encrypt().

Since it appears that the Mozillians are too nice to say anything about it, this bug is blocking Mozilla bug 790487, which is causing the email report mechanism for security-critical bugs at Mozilla to not function correctly. Since I'm not a Mozillian, I don't mind pointing being the asshole who points out that you're fucking their shit up.

Copy link

towo commented Oct 18, 2016

FWIW, this is not entirely correct. The test e-mail gets sent successfully and to the right address, just other mails are an issue.

Copy link

towo commented Nov 29, 2016

Another FYI update - we assumed this was a partial bug related to this, but the most "recent" version of the securemail extension ( solved our issues.

Copy link

sysrqb commented Apr 14, 2018

This is still a problem. I just received an email from encrypted using my primary public key. Has anyone looked at this? Is Isis' suggestion regarding what's causing this wrong or was it ignored?


Copy link

teythoon commented Jun 1, 2021

AFAICS Crypt::OpenPGP considers RSA keys encryption-capable without looking at the relevant binding signature's key flags subpacket:

 % git grep can_encrypt
lib/Crypt/OpenPGP/ can_encrypt { $_[0]->{key}->can_encrypt }
lib/Crypt/OpenPGP/ $cert->can_encrypt
lib/Crypt/OpenPGP/ can_encrypt { 0 }
lib/Crypt/OpenPGP/ $key->can_encrypt
lib/Crypt/OpenPGP/Key/Public/ can_encrypt { 1 }
lib/Crypt/OpenPGP/Key/Public/ can_encrypt { 1 }
lib/Crypt/OpenPGP/Key/Secret/*can_encrypt = \&Crypt::OpenPGP::Key::Public::ElGamal::can_encrypt;
lib/Crypt/OpenPGP/Key/Secret/*can_encrypt = \&Crypt::OpenPGP::Key::Public::RSA::can_encrypt;
lib/Crypt/OpenPGP/        return $key if $key->can_encrypt;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

7 participants