search

kazu-yamamoto / pgpdump

A PGP packet visualizer
http://www.mew.org/~kazu/proj/pgpdump/
BSD 3-Clause "New" or "Revised" License
174 stars 33 forks source link

pgpdump fails to parse secret key #26

Open teythoon opened 6 years ago

teythoon commented 6 years ago 
% cat  ../../weird-keys/two.pgp
-----BEGIN PGP PRIVATE KEY BLOCK-----

xVgEWxpOHRYJKwYBBAHaRw8BAQdAxq7YVmI0c+fxhv9fCd3SwrVIvXiUkKjS/Zz8
xmkV+4YAAP9QXswTMSNZScLMSB186DmFrDYvdv9a5dYJaMbn3ssAXBBVzRpUd28g
RmlzaCA8dHdvQGV4YW1wbGUub3JnPsJ+BBMWCgAwApsDBYJbGk4dBYkB3+IAFqEE
K3dX2K8oNGigV0aZkQ5VRHjM3gAJkJEOVUR4zN4AAAC9/AD9F+KyqaTdSZxn6KKd
grcOiunuxA1pZ/bP2TYBWLXoirQA+wTm9K2aSc9YulbJcFF3XKQJDzvKeDyknok+
TVzYIVMIx10EWxpOHRIKKwYBBAGXVQEFAQEHQEr7lcszstnVdhkTOYGfZJuYQznG
pfz2/Jydug3Mmn19AwEKCQAA/3jWHYWk3UY4L9aqcHwJj9VdKxrjP5soyUx1Uey/
4dUYENHCfgQYFgoAMAKbDAWCWxpOHQWJAd/iABahBCt3V9ivKDRooFdGmZEOVUR4
zN4ACZCRDlVEeMzeAAAAllIBAPrKUhqobdgqYkK2sz6Rmh+EYFKDfQw2/PEfdRU4
WGuWAP9RR1cEVzArXFgjfuyoeFjH7eUUY8+mLcpzEgKrykhxD8ddBFsaTh0SCisG
AQQBl1UBBQEBB0AZvZWhCE0hWegUjFz193npbGPib3EmdzgbbrfjefDNNAMBCgkA
AP9e5eLZhejDULF5JI9OQ7mCrabEEYbuoPy2njhHJa5XwBMbwn4EGBYKADACmwwF
glsaTh0FiQHf4gAWoQQrd1fYryg0aKBXRpmRDlVEeMzeAAmQkQ5VRHjM3gAAAAj2
AP0bD/gR70zkMKwC3+dEpPZ41+gyjlrrrHbGMiaBEzug5QD/e3I6t5XtPbRg66np
GwsOQiY1zEbCH/CpCRO3w/OQUgM=
=+0IG
-----END PGP PRIVATE KEY BLOCK-----
% ./pgpdump ../../weird-keys/two.pgp
New: Secret Key Packet(tag 5)(88 bytes)
        Ver 4 - new
        Public key creation time - Fri Jun  8 11:36:29 CEST 2018
        Pub alg - EdDSA Edwards-curve Digital Signature Algorithm(pub 22)
        Unknown public key(pub 22)
        Sym alg - unknown(sym 205)
        Simple string-to-key for IDEA
        IV - 
        Unknown encrypted key(pub 22)
        Encrypted checksum
Old: Public Key Packet(tag 6)(1417113376 bytes)
pgpdump: unknown version (70).
        Ver 70 -

FTR, three OpenPGP implementations including GnuPG parsed the key just fine.

kazu-yamamoto commented 6 years ago

pgpdump does not provide the function to decrypt encrypted packets yet.

teythoon commented 6 years ago

I don't want it to decrypt the key, but note how the parsing fails. E.g. pgpdump thinks the second packet is an old-style packet (it is a new-style one) of length 1417113376.

For reference, here is the packet as parsed by gpg:

% gpg --list-packets ../weird-keys/two.pgp
# off=0 ctb=c5 tag=5 hlen=2 plen=88 new-ctb
:secret key packet:
        version 4, algo 22, created 1528450589, expires 0
        pkey[0]: [80 bits] ed25519 (1.3.6.1.4.1.11591.15.1)
        pkey[1]: [263 bits]
        skey[2]: [255 bits]
        checksum: 1055
        keyid: 910E554478CCDE00
# off=90 ctb=cd tag=13 hlen=2 plen=26 new-ctb
:user ID packet: "Two Fish <two@example.org>"
# off=118 ctb=c2 tag=2 hlen=2 plen=126 new-ctb
:signature packet: algo 22, keyid 910E554478CCDE00
        version 4, created 1528450589, md5len 0, sigclass 0x13
        digest algo 10, begin of digest bd fc
        critical hashed subpkt 27 len 1 (key flags: 03)
        critical hashed subpkt 2 len 4 (sig created 2018-06-08)
        critical hashed subpkt 9 len 4 (key expires after 364d0h0m)
        critical hashed subpkt 33 len 21 (issuer fpr v4 2B7757D8AF283468A0574699910E554478CCDE00)
        critical hashed subpkt 16 len 8 (issuer key ID 910E554478CCDE00)
        data: [253 bits]
        data: [251 bits]
# off=246 ctb=c7 tag=7 hlen=2 plen=93 new-ctb
:secret sub key packet:
        version 4, algo 18, created 1528450589, expires 0
        pkey[0]: [88 bits] cv25519 (1.3.6.1.4.1.3029.1.5.1)
        pkey[1]: [263 bits]
        pkey[2]: [32 bits]
        skey[3]: [255 bits]
        checksum: 10d1
        keyid: E3204A06DD5C53CD
# off=341 ctb=c2 tag=2 hlen=2 plen=126 new-ctb
:signature packet: algo 22, keyid 910E554478CCDE00
        version 4, created 1528450589, md5len 0, sigclass 0x18
        digest algo 10, begin of digest 96 52
        critical hashed subpkt 27 len 1 (key flags: 0C)
        critical hashed subpkt 2 len 4 (sig created 2018-06-08)
        critical hashed subpkt 9 len 4 (key expires after 364d0h0m)
        critical hashed subpkt 33 len 21 (issuer fpr v4 2B7757D8AF283468A0574699910E554478CCDE00)
        critical hashed subpkt 16 len 8 (issuer key ID 910E554478CCDE00)
        data: [256 bits]
        data: [255 bits]
# off=469 ctb=c7 tag=7 hlen=2 plen=93 new-ctb
:secret sub key packet:
        version 4, algo 18, created 1528450589, expires 0
        pkey[0]: [88 bits] cv25519 (1.3.6.1.4.1.3029.1.5.1)
        pkey[1]: [263 bits]
        pkey[2]: [32 bits]
        skey[3]: [255 bits]
        checksum: 131b
        keyid: 24BE06577511DD62
# off=564 ctb=c2 tag=2 hlen=2 plen=126 new-ctb
:signature packet: algo 22, keyid 910E554478CCDE00
        version 4, created 1528450589, md5len 0, sigclass 0x18
        digest algo 10, begin of digest 08 f6
        critical hashed subpkt 27 len 1 (key flags: 0C)
        critical hashed subpkt 2 len 4 (sig created 2018-06-08)
        critical hashed subpkt 9 len 4 (key expires after 364d0h0m)
        critical hashed subpkt 33 len 21 (issuer fpr v4 2B7757D8AF283468A0574699910E554478CCDE00)
        critical hashed subpkt 16 len 8 (issuer key ID 910E554478CCDE00)
        data: [253 bits]
        data: [255 bits]
HeikoStamer commented 5 years ago

I guess this issue is due to algorithm-specific fields for EdDSA keys (cf. draft RFC 4880bis) that are not supported by pgpdump.