Page MenuHome GnuPG

gpgsm certificate import fails because of hardcoded password length limitation
Open, LowPublic

Description

gpgsm (GnuPG) 2.2.6
libgcrypt 1.8.2
libksba 1.3.5

I've switched from Thunderbird to Kontact and therefore also migrated my SMIME certificates. However when attempting to import them I constantly ran into an error message. Kleopatra reported "invalid object".

Checking the logs revealed that gpgsm thinks the password is too long:

gpgsm[8059]: password too long

I've set a 64 character password for each of my certificate passphrases, however never ran into issues until now. It seems like there's a hardcoded 31 character limit in the code.

The offending line can be found here:
https://github.com/gpg/gnupg/blob/cdc8d0bd933b958db878861587322bc541b580b3/sm/minip12.c#L344

NIST's guidelines of allowing a maximum password length of at least 64 characters seems like a good start. Since the password is hashed anyway one could also argue that this limit is unnecessary as well.

Regardless this seems like it's worth looking into.

Details

Version
2.2.6

Event Timeline

werner added a project: S/MIME.
werner added a subscriber: werner.

This for importing passwords using a somewhat heuristic approach to accommodate for all the weird things other PKCS#12 implementations do. I have not looked into the specs for a decade and thus can't tell you the reason for that limitations. There might have been one back then. In any case PKCS#12 is the most insecure things in the PKCS suite and it is questionable whether this can be called a standard.

The workaround is easy: Change the passphrase , export, import and then set a longer passphrase again. If you really want to do that -it has no security benefit for a passphrase protecting a private key. There are way easier methods to get to the private key than to brute force an even 32 character passphrase. Note that pinentry also has a limit on the length of the passphrase but it is larger than 64 characters.

I tend to mark this has won't fix unless we can figure out why I made that decision more than 15 years ago.

The workaround is easy: Change the passphrase , export, import and then set a longer passphrase again.

So I know of users who get pkcs#12 certificates, import them in firefox to export them so that they can be used in GnuPG. This is, and feels to users, stupid.

If you really want to do that -it has no security benefit for a passphrase protecting a private key. There are way easier methods to get to the private key than to brute force an even 32 character passphrase

Of course. But S/MIME CA's are stupid. They think longer is more secure and send such keys to their users. I know that V-PKI does this.

So to tl;dr;: Customers get such keys, the passphrase is out of their control. They have to workaround this limitation. Not good.