Passphrase problem in gpgsm 2.0.14

Werner Koch wk at
Tue Jan 26 15:36:06 CET 2010


While preparing a new release of Gpg4win we found a regression in GnuPG
2.0.14.  The problem is due to this change:

 * New and changed passphrases are now created with an iteration count
   requiring about 100ms of CPU work.

I don't know how it slipped through my tests, but somehow it happend.
The bug occurs in all cases where gpg-agent creates a new protected key
or changes the protection.  For example:

 - You import a new private key with GPGSM from a PKCSC#12 file.

 - You change the passphrase of a X.509 key (gpgsm --passwd)

 - You create or import a new on-disk Secure Shell key.

It does not affect keys or passphrases related to GPG (OpenPGP keys).

The bug is that the new iteration count is not encoded in the file.
Instead the old constant value of 65536 (encoded as 96) is written to
the file.  If you now try to use the key and enter the passphrase,
gpg-agent uses the wrong iteration count from the file (65536) and thus
can't unprotect the key.

A patch against 2.0.14 is attached.

It is possible to fixup the wrong iteration counts but before I add such
a feature, I would like to know whether this is really needed.

 - If you imported a p12 file you may simply re-import that file after
   deleting the old file.  To find the respective file with the private
   key, you use this command

     gpgsm --dump-cert KEYID | grep keygrip:

   The hex-string you see is the basename of private key.  For example:

     $ gpgsm --dump-cert 0x036A1456 | grep keygrip:
         keygrip: 25268070E915E1E3DCCBD9EBEF18BCEF9B0AB289

     $ ls -l private-keys-v1.d/25268070E915E1E3DCCBD9EBEF18BCEF9B0AB289.key

   You better delete this file before importing the p12 file again:

     $ rm private-keys-v1.d/25268070E915E1E3DCCBD9EBEF18BCEF9B0AB289.key

 - If you changed the passphrase and you have a backup of the private
   key, it will be easier to use the backup.

 - If you did not changed the passphrase, you don't have any problem.

 - If there is no other way to restore it, please complain and I will
   write a tool to fixup the mess.

I am sorry for the possible trouble.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg-2.0.14-encode-s2k.patch
Type: text/x-patch
Size: 1384 bytes
Desc: not available
URL: </pipermail/attachments/20100126/17291872/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 204 bytes
Desc: not available
URL: </pipermail/attachments/20100126/17291872/attachment.pgp>

More information about the Gnupg-users mailing list