Wrong passphrase

[GoogleCodeExporter]

I have a key that I regularly use with GnuPG-1.4.x & TB & Enigmail, and  with 
Gpg4Win-2.x & TB & Enigmail (on 2 different systems) and gpg on linux. 

APG is 1.0.9. It happily imported the key, I can use the public part to 
encrypt, but I cannot decrypt, nor can I modify anything in key management. 
It always says "wrong pass phrase". 
Tried the default system keyboard and hacker's keyboard. 

My key is RSA, 8k (used instructions found on the net how to patch gpg to allow 
it to generate larger then 4k keys, which is already a debated limitation all 
over) with a signing subkey and an encryption subkey. 

As stated, Enigmail works happily with it, no problems. 
Key defaults are SHA256 and AES256. 

What steps will reproduce the problem?
1. generate an 8k key using linux gpg. export both secret and public part.
2. import both files into APG
3. try to perform any operation which requires secret key passphrase

Original issue reported on code.google.com by andrixnet on 24 Oct 2013 at 5:12

[GoogleCodeExporter]

I have tested with several test keys. 
It is clearly related to differences between gnupg and APG. 
I have generated a 2k key with the same gnupg installation and it also failed. 
This build also has several configuration enhancements designed for a stronger 
key

I have generated a 2k key with a different gnupg build (without such 
enhancements) and it worked, passphrase was accepted. 

Clearly, it is not the key size (I also noted that APG can be asked to generate 
an 8k key). 
I am trying to determine which option might be at fault.

Original comment by andrixnet on 24 Oct 2013 at 5:35

[GoogleCodeExporter]

Indeed, the problem are the enhanced options, some of which apparently are not 
supported by APG. 

The options are : (they control the encryption of the private key in your 
keyring)
#s2k-cipher-algo AES256
default is CAST5 (man gpg)
#s2k-digest-algo SHA256
default is SHA-1 (man gpg)

I have set these to the above values based on recommendations I found on the 
internet. I leave the debate on the strength comparison between CAST5 and 
AES256 to others, but SHA-1 has been already demonstrated to have weaknesses. 
Some info can be found here: 
https://www.schneier.com/blog/archives/2005/02/sha1_broken.html

Since GnuPG is widely versatile, it is a definite improvement to configure it 
to use stronger algorithms if they are available and pretty widely supported. 

APG, working on Android, and more significantly, used on smartphones and 
tablets, which clearly are more prone to be lost or stolen then a laptop, and 
even more then a desktop. 
APG must definitely provide strong crypto for your on-board keys. 

Tested : 

1) generate a key with these options in gpg.conf: 
s2k-cipher-algo AES256
s2k-digest-algo SHA256

APG is unable to access the private key. 

I tried combinations of one option enabled, one disabled. APG is still unable.

2) generate a key using the defaults in gpg.conf (ie comment these)
#s2k-cipher-algo AES256
#s2k-digest-algo SHA256

APG works with the private key. 

This bug is consequently a feature request : APG should support all the 
crypto/hash algorithms for private key encryption as well. 
Since APG already supports these for message encryption, it shouldn't be too 
hard to implement. 

Thank you. 

Original comment by andrixnet on 24 Oct 2013 at 8:16

[GoogleCodeExporter]

WORKAROUND: 

At this time, some stronger crypto/hash algorithms for secret key encryption 
are not supported by APG. 

If you key was generated by a gpg using s2k-*-algo options you have to do the 
following:
1) import you provate key into gpg
2) edit gpg.conf and comment s2k-*-algo options (gpg will use the defaults)
3) edit your key (gpg --edit-key ID)
4) change your password (using passwd command in interractive gpg session)
5) save your changes
6) export your secret key (ie gpg --armour --export-secret-keys --output 
key.asc ID)
7) import your key into APG

Now the key is encrypted using the default algo and APG works with it. 

Beware though that your secret key stored in you Android device may be less 
protected then the key you have in your PC generated with options such as the 
above. 

Original comment by andrixnet on 24 Oct 2013 at 8:27