Description of problem:
gnupg2 2.0.14 has a known regression bug that in all cases where gpg-agent creates a new protected key or changes the protection fails to encode a new iteration count into the file.  Instead the old constant value of 65536 (encoded as 96) is written to the file.  If you then 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.

The end result is that one is unable to properly interact with gpg-agent.  Specifically kmail cannot s/mime sign email, kleopatra cannot decrypt previously encrypted files, and gpgsm decryption fails.

Described by Werner Koch (developer) @:
http://marc.info/?l=gnupg-users&m=126451730710129&w=2
Patch provided @:
ftp://ftp.gnupg.org/gcrypt/gnupg/patches/gnupg-2.0.14-encode-s2k.patch

Version-Release number of selected component (if applicable):
Fedora 13
gnupg2-2.0.14-6.fc13.i686
gnupg2-smime-2.0.14-6.fc13.i686

How reproducible:
Always
According to above post, happens whenever gpg-agent (version 2.0.14) is used.

Steps to Reproduce:
Assuming you have an existing gpgsm certificate pair.
1. Create random text file - trash.txt
2. gpgsm -r <your key id> -o trast.txt.gpg -e trash.txt
3. gpgsm -d trast.txt.gpg
  
Actual results:
passphrase input fails, secret key decryption failure, contents of trast.txt.gpg cannot be seen

Expected results:
contents of trast.txt.gpg decrypted

Additional info:
Applying provided vendor patch to 2.0.14-6 src rpm, rebuilding (via specfile updates), and upgrading gnupg2 installation corrects this issue.