Checksum error when importing unencrypted ECC private keys

Wed Jul 22 09:26:04 CEST 2015

When trying to import unencrypted ECDSA/ECDH private key into GnuPG
2.1.5/2.1.6, I'm getting the following error:

gpg: key F8BE8F0F/F8BE8F0F: error sending to agent: Checksum error

The same key imports correctly once it's encrypted to a passphrase,
also the public key imports ok. Keypair has been generated by Google
End-To-End.

The issue, together with the offending key, is described in greater
details at https://github.com/google/end-to-end/issues/326#issuecomment-123585977,
but the keypair is basically:

# off=0 ctb=c5 tag=5 hlen=6 plen=165 new-ctb
:secret key packet:
version 4, algo 19, created 0, expires 0
pkey[0]: [72 bits] nistp256 (1.2.840.10045.3.1.7)
pkey[1]: [515 bits]
iter+salt S2K, algo: 9, SHA1 protection, hash: 2, salt: C976A61DE8AFB85D
protect count: 65536 (96)
protect IV:  02 38 f0 2b 32 04 1f 69 41 6d 41 8e 78 a5 14 b5
skey[2]: [v4 protected]
keyid: 03288C74F8BE8F0F
# off=171 ctb=cd tag=13 hlen=6 plen=22 new-ctb
:user ID packet: "<example at another.test>"
# off=199 ctb=c2 tag=2 hlen=6 plen=141 new-ctb
:signature packet: algo 19, keyid 03288C74F8BE8F0F
version 4, created 1437396427, md5len 0, sigclass 0x10
digest algo 8, begin of digest 88 12
critical hashed subpkt 2 len 4 (sig created 2015-07-20)
critical hashed subpkt 11 len 1 (pref-sym-algos: 9)
critical hashed subpkt 16 len 8 (issuer key ID 03288C74F8BE8F0F)
critical hashed subpkt 21 len 4 (pref-hash-algos: 8 9 10 11)
critical hashed subpkt 22 len 2 (pref-zip-algos: 1 2)
critical hashed subpkt 27 len 1 (key flags: 03)
critical hashed subpkt 30 len 1 (features: 01)
data: [252 bits]
data: [253 bits]
# off=346 ctb=c7 tag=7 hlen=6 plen=169 new-ctb
:secret sub key packet:
version 4, algo 18, created 0, expires 0
pkey[0]: [72 bits] nistp256 (1.2.840.10045.3.1.7)
pkey[1]: [515 bits]
pkey[2]: [32 bits]
iter+salt S2K, algo: 9, SHA1 protection, hash: 2, salt: CA65C8117A0CDB81
protect count: 65536 (96)
protect IV:  2d ed 4f 26 04 2f 44 10 8d 6a dc 69 a7 93 93 82
skey[3]: [v4 protected]
keyid: A6ED196C7C513F1E
# off=521 ctb=c2 tag=2 hlen=6 plen=109 new-ctb
:signature packet: algo 19, keyid 03288C74F8BE8F0F
version 4, created 1437396427, md5len 0, sigclass 0x18
digest algo 8, begin of digest f3 c1
critical hashed subpkt 2 len 4 (sig created 2015-07-20)
critical hashed subpkt 16 len 8 (issuer key ID 03288C74F8BE8F0F)
critical hashed subpkt 27 len 1 (key flags: 0C)
data: [256 bits]
data: [256 bits]
# off=636 ctb=c6 tag=6 hlen=6 plen=82 new-ctb
:public key packet:
version 4, algo 19, created 0, expires 0
pkey[0]: [72 bits] nistp256 (1.2.840.10045.3.1.7)
pkey[1]: [515 bits]
keyid: 03288C74F8BE8F0F
# off=724 ctb=cd tag=13 hlen=6 plen=22 new-ctb
:user ID packet: "<example at another.test>"
# off=752 ctb=c2 tag=2 hlen=6 plen=141 new-ctb
:signature packet: algo 19, keyid 03288C74F8BE8F0F
version 4, created 1437396427, md5len 0, sigclass 0x10
digest algo 8, begin of digest 88 12
critical hashed subpkt 2 len 4 (sig created 2015-07-20)
critical hashed subpkt 11 len 1 (pref-sym-algos: 9)
critical hashed subpkt 16 len 8 (issuer key ID 03288C74F8BE8F0F)
critical hashed subpkt 21 len 4 (pref-hash-algos: 8 9 10 11)
critical hashed subpkt 22 len 2 (pref-zip-algos: 1 2)
critical hashed subpkt 27 len 1 (key flags: 03)
critical hashed subpkt 30 len 1 (features: 01)
data: [252 bits]
data: [253 bits]
# off=899 ctb=ce tag=14 hlen=6 plen=86 new-ctb
:public sub key packet:
version 4, algo 18, created 0, expires 0
pkey[0]: [72 bits] nistp256 (1.2.840.10045.3.1.7)
pkey[1]: [515 bits]
pkey[2]: [32 bits]
keyid: A6ED196C7C513F1E
# off=991 ctb=c2 tag=2 hlen=6 plen=109 new-ctb
:signature packet: algo 19, keyid 03288C74F8BE8F0F
version 4, created 1437396427, md5len 0, sigclass 0x18
digest algo 8, begin of digest f3 c1
critical hashed subpkt 2 len 4 (sig created 2015-07-20)
critical hashed subpkt 16 len 8 (issuer key ID 03288C74F8BE8F0F)
critical hashed subpkt 27 len 1 (key flags: 0C)
data: [255 bits]
data: [256 bits]

-----BEGIN PGP PRIVATE KEY BLOCK-----
Charset: UTF-8
Version: End-To-End v0.3.1342

xf8AAAClBAAAAAATCCqGSM49AwEHAgMEmUwnXtxBvQY+nXvduAbd626NmYshRVi4
HULGQ9fAHjKqfld4qWk97o+ggZDAnhQJ/Jm3ljtXr3/SosXUsSh7AP4JAwLJdqYd
6K+4XWACOPArMgQfaUFtQY54pRS1Vo98N4Jpw7o0iYAr80y40s5DaBIcUD5UuMHM
p5no4vv8/hVCkIWJvoD/08rIzJDYEc9h2S4Lzf8AAAAWPGV4YW1wbGVAYW5vdGhl
ci50ZXN0PsL/AAAAjQQQEwgAP/8AAAAFglWs7cv/AAAAAosJ/wAAAAmQAyiMdPi+
jw//AAAABZUICQoL/wAAAAOWAQL/AAAAApsD/wAAAAKeAQAAiBIA/AvNA8R65IiA
QxxeRFoLszPoFE2+MZiHUwCdsBlDp0zqAP0aVriTSlN5HbZ55qnHvPP/4zfFRdR6
NATjR9W+3UVeIsf/AAAAqQQAAAAAEggqhkjOPQMBBwIDBMn29++Qg1NOQtwV4xWN
7RmxhJhq04DY9JQM3W4u01ZubYh4nXDVjx0kD0vGjJsoB9tzryJEwZiXQh0d/JRi
A/4DAQgH/gkDAsplyBF6DNuBYC3tTyYEL0QQjWrcaaeTk4JSb93mog6QlL610EO5
+muowWT9Dl8Ll77BjQSpj7mmqGHIj/IxJubOYqa+iW1e4pj5qlXCaBbC/wAAAG0E
GBMIAB//AAAABYJVrO3L/wAAAAmQAyiMdPi+jw//AAAAApsMAADzwQEAq95OmyQ8
3XRyVDpN4IWqWrnWOEHlmHM9KrrgKEHunycBAJr1olmd5A68wOq43/W+kkoy8Mcd
cH4SAiy4DMvQO18vxv8AAABSBAAAAAATCCqGSM49AwEHAgMEmUwnXtxBvQY+nXvd
uAbd626NmYshRVi4HULGQ9fAHjKqfld4qWk97o+ggZDAnhQJ/Jm3ljtXr3/SosXU
sSh7AM3/AAAAFjxleGFtcGxlQGFub3RoZXIudGVzdD7C/wAAAI0EEBMIAD//AAAA
BYJVrO3L/wAAAAKLCf8AAAAJkAMojHT4vo8P/wAAAAWVCAkKC/8AAAADlgEC/wAA
AAKbA/8AAAACngEAAIgSAPwLzQPEeuSIgEMcXkRaC7Mz6BRNvjGYh1MAnbAZQ6dM
6gD9Gla4k0pTeR22eeapx7zz/+M3xUXUejQE40fVvt1FXiLO/wAAAFYEAAAAABII
KoZIzj0DAQcCAwTJ9vfvkINTTkLcFeMVje0ZsYSYatOA2PSUDN1uLtNWbm2IeJ1w
1Y8dJA9LxoybKAfbc68iRMGYl0IdHfyUYgP+AwEIB8L/AAAAbQQYEwgAH/8AAAAF
glWs7cv/AAAACZADKIx0+L6PD/8AAAACmwwAAPPBAP9qFpKqiAx+VKUYlFRnpBvn
UQBpgEHmcv+7VyRYuH8IIQEAzzcIXOHWolfNieXkMk0A+ePiMmAkq1LE6Gdu+WTr
bDE=
=Sgsj
-----END PGP PRIVATE KEY BLOCK-----

It seems to be the same issue as mentioned in
https://lists.gnupg.org/pipermail/gnupg-devel/2015-January/029444.html
(was it fixed then?).

-- 
koto@ / Krzysztof Kotowicz / Google