kazu-yamamoto / pgpdump Goto Github PK

View Code? Open in Web Editor NEW

171.0 11.0 32.0 304 KB

A PGP packet visualizer

Home Page: http://www.mew.org/~kazu/proj/pgpdump/

License: BSD 3-Clause "New" or "Revised" License

C 79.97% Makefile 2.33% Roff 2.28% Shell 9.80% ReScript 4.28% M4 1.34%

pgpdump's Introduction

pgpdump: a PGP packet visualizer

Kazu Yamamoto [email protected]
August 16, 2010

Overview

pgpdump is a PGP packet visualizer which displays the packet format of OpenPGP (RFC 4880) and PGP version 2 (RFC 1991).

Here is an example:

% pgpdump test/sig1
Old: Marker Packet(tag 10)(3 bytes)
	String - ...
New: One-Pass Signature Packet(tag 4)(13 bytes)
	New version(3)
	Sig type - Signature of a binary document(0x00).
	Hash alg - SHA1(hash 2)
	Pub alg - DSA Digital Signature Algorithm(pub 17)
	Key ID - 0xA79778E247B63037
	Next packet - other than one pass signature
New: Signature Packet(tag 2)(63 bytes)
	Ver 3 - old
	Hash material(5 bytes):
		Sig type - Signature of a binary document(0x00).
		Creation time - Fri Nov 27 22:35:02 JST 1998
	Key ID - 0xA79778E247B63037
	Pub alg - DSA Digital Signature Algorithm(pub 17)
	Hash alg - SHA1(hash 2)
	Hash left 2 bytes - 8f 82
	DSA r(160 bits) - ...
	DSA s(157 bits) - ...
		-> hash(DSA q bits)

Installation

Take the following steps to install pgpdump from a release tarball:

% ./configure
% make
% su
# make install

To build from Git, run autoreconf -fviW all before running the above commands.

Binaries are available for Mac OS X via Homebrew:

% brew install pgpdump

Usage

To know how to use pgpdump, type pgpdump -h.

Some examples are stored in the test directory. Also, you can visualize your pubring and secring.

Home page

The official home page of pgpdump is:

https://www.mew.org/~kazu/proj/pgpdump/

Bugs

pgpdump assumes that a compressed packet continues until the end of the specified file.

Testing

To run all of the tests:

% make check

or:

% make
% ./test/test

To run specific tests:

% make check TESTS="test/pub.res test/sig.res"

or:

% make
% ./test/test test/pub.res test/sig.res

pgpdump's People

Contributors

Stargazers

Watchers

pgpdump's Issues

new release? (include changes since 0.35)

I see there are a few changes merged since v0.35 for over a year now, but they are not part of a release. Should version 0.36 be tagged and released, or do you have pending work that you expect to make it into the next release?

should dump notation names (and not hex values) even if the value is not human readable

I will copy here the report for Debian located on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464572 :

8<-------

The RFC4880 states, that names are always UTF-8 encoded strings, so
they are always "readable", while values are not. Thus, I think that
names should be dumped as strings, while the readability should only
be examined while dumping the value.

Here is the patch for this change:
--- subfunc.c.orig 2008-02-07 15:39:06.996720105 +0100
+++ subfunc.c 2008-02-07 15:39:18.547170952 +0100
@@ -163,10 +163,7 @@
vlen = Getc() * 256;
vlen += Getc();
printf("\t\tName - ");

```
  if (human)
```
```
          pdump(nlen);
```
```
  else
```
```
          dump(nlen);
```

  pdump(nlen);
printf("\n");
printf("\t\tValue - ");
if (human)

------->8

Hoping to hear soon of you :-)
Regards

pgpdump fails to parse secret key

% 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.

pgpdump reports key expiration time as absolute instead of relative

pgpdump states a key expiration time subpacket as an absolute time in seconds since the epoch, but https://tools.ietf.org/html/rfc4880#section-5.2.3.6 indicates that it should be read as "seconds after key creation" instead. compare with gpg --list-packets:

0 dkg@alice:/tmp/cdtemp.Tvk0D4$ pgpdump < 000015-002.sig 
Old: Signature Packet(tag 2)(549 bytes)
	Ver 4 - new
	Sig type - Subkey Binding Signature(0x18).
	Pub alg - RSA Encrypt or Sign(pub 1)
	Hash alg - SHA512(hash 10)
	Hashed Sub: key flags(sub 27)(1 bytes)
		Flag - This key may be used for authentication
	Hashed Sub: signature creation time(sub 2)(4 bytes)
		Time - Wed Jan 21 15:54:17 EST 2015
	Hashed Sub: key expiration time(sub 9)(4 bytes)
		Time - Thu Aug  4 01:50:07 EDT 1977
	Sub: issuer key ID(sub 16)(8 bytes)
		Key ID - 0xCCD2ED94D21739E9
	Hash left 2 bytes - 98 20 
	RSA m^d mod n(4094 bits) - ...
		-> PKCS-1
0 dkg@alice:/tmp/cdtemp.Tvk0D4$ gpg2 --list-packets < 000015-002.sig 
# off=0 ctb=89 tag=2 hlen=3 plen=549
:signature packet: algo 1, keyid CCD2ED94D21739E9
	version 4, created 1421873657, md5len 0, sigclass 0x18
	digest algo 10, begin of digest 98 20
	hashed subpkt 27 len 1 (key flags: 20)
	hashed subpkt 2 len 4 (sig created 2015-01-21)
	hashed subpkt 9 len 4 (key expires after 7y217d5h50m)
	subpkt 16 len 8 (issuer key ID CCD2ED94D21739E9)
	data: [4094 bits]
0 dkg@alice:/tmp/cdtemp.Tvk0D4$

in particular, the claim about 1977 in pgpdump is bogus :)

it should either display the expiration date as a temporal offset, or it should calculate the actual absolute date.

Skips any additional signatures

Hi,

Can you take a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745193 ?

Potential Confusing Output in "Literal Data Packet" Dump

…
Old: Literal Data Packet(tag 11)(3914 bytes)
	Format - binary
	Filename - File.txt
	File modified time - Thu Jan 30 23:40:48 CET 2020
	Literal - ...
…

That "File modified time" label in a signature dump suggests the timestamp is the modified time of the file that got signed ("File.txt"), but it actually seems to be the "Created" date of the signature itself (that's how GnuPG does it here at least.) So the used label "File modified time" in this case is misleading, IMHO. Similar for the "Format".

RFC 4880 states the following: "A four-octet number that indicates a date associated with the literal data. Commonly, the date might be the modification date of a file, or the time the packet was created, or a zero that indicates no specific time."; I assume there's no way to distinguish between an actual file creation date vs. the packet creation date, so the label should be open to both interpretations, I guess.

My recommendation to make dumped information more clear to the user:

…
Old: Literal Data Packet(tag 11)(3914 bytes)
	Packet data format - binary
	Creation time - Thu Jan 30 23:40:48 CET 2020
	Filename - File.txt
	Literal - ...
…

How do you compile the tests?

After about 2 hours of bootstrapping a haskell environment, figuring out what dependencies it needs, installing the dependencies, and having no clue how to resolve:

$ ghc test.hs

test.hs:7:8:
    Ambiguous module name ‘Test.Framework’:
      it was found in multiple packages:
      HTF-0.13.0.0 test-framework-0.8.1.1

$ ghc test.hs

test.hs:7:8:
    Could not find module ‘Test.Framework’
    It is a member of the hidden package ‘HTF-0.13.0.0’.
    It is a member of the hidden package ‘test-framework-0.8.1.1’.
    Use -v to see a list of the files searched for.

$ ghc -package HTF test.hs
[1 of 1] Compiling Test             ( test.hs, test.o )

test.hs:7:24: Module ‘Test.Framework’ does not export ‘defaultMain’

test.hs:7:37: Module ‘Test.Framework’ does not export ‘testGroup’

test.hs:7:48: Module ‘Test.Framework’ does not export ‘Test’

$ ghc -package test-framework test.hs
$ ./test
no such file or directory: ./test
$ ghc -package test-framework test.hs -o IHaveNoClueWhatImDoing
Warning: output was redirected with -o, but no output will be generated
because there is no Main module.

I found https://github.com/kazu-yamamoto/unit-test-example but still have no clue what to do.

I just give up. Any hints?

Documentation

I just discovered pgpdump, and I really appreciate the effort that the authors have put in here, so let me start with a big THANK YOU!

It really helps me to get to understand the DETAILS.

What I'm missing is some documentation. For example, in this output:

Old: Secret Subkey Packet(tag 7)(889 bytes)
    Ver 4 - new

I was confused about the "Old" (especially in conjuction with the "Ver 4 - new"). It would help me to understand what's old and what's new. I looked at the source code, but unfortunately, there were no comments in their either, leaving me to guess if the ver() routine referred to "version", "verbose" or something else.

Updating pgpdump-33 for new Elliptic curves from "draft-ietf-openpgp-crypto-refresh-04"

I have been working with pgpdump-33 code to include:

description of pubic key algortihm 18 from RFC 6637
definitions and display for new OpenPGP Message Format elliptic curves from the refresh-04 draft, Table 17, page 84

I have already made the changes for #1 locally. I have created test code to implement the basics for #2, and will work on merging those changes locally.

Update CHANGES

Hi Kazu,

Seems like you forgot to update CHANGES for 0.29. Let me suggest the following:

0.29 2014/08/01

Adaption for Fedora packaging.
Ignore whitespace when decoding Radix-64 input.
Add support for GnuPG extensions in private subkeys.

Cheers

gpg tag 20

I built the latest version of pgpdump (0.35) and an encrypted file I have says "unknown(tag 20)", just like the older version of pgpdump installed on my system.

# /opt/bin/pgpdump encryptedfile
Old: Public-Key Encrypted Session Key Packet(tag 1)(524 bytes)
	New version(3)
	Key ID - 0xDCE2000000000000
	Pub alg - RSA Encrypt or Sign(pub 1)
	RSA m^e mod n(4095 bits) - ...
		-> m = sym alg(1 byte) + checksum(2 bytes) + PKCS-1 block type 02
New: unknown(tag 20)(65536 bytes) partial start
New: 	(65536 bytes) partial continue
...snip...
New: 	(461 bytes) partial end

getsops/sops#896 leads me to think that "tag 20" might be a new tag, "AEAD Encrypted Data Packet", from draft-ietf-openpgp-rfc4880bis-06.

If this is the case, is there a plan for pgpdump to support it?

pgpdump fails to dump OpenPGP RSA key generated using Bouncycastle

Hi!
I came across pgpdump failing to dump keys generated using bouncycastle 1.59.

Here is an example key:

pgpdump gives me this output:

$pgpdump bc.sec
Old: Secret Key Packet(tag 5)(938 bytes)
	Ver 4 - new
	Public key creation time - Tue May 15 08:59:49 CEST 2018
	Pub alg - RSA Encrypt or Sign(pub 1)
	RSA n(2048 bits) - ...
	RSA e(17 bits) - ...
	RSA d(2043 bits) - ...
	RSA p(1024 bits) - ...
	RSA q(1024 bits) - ...
	RSA u(1022 bits) - ...
	Checksum - 7f 2a 
Old: One-Pass Signature Packet(tag 4)(26 bytes)
	Unknown version(35)
	Sig type - unknown(91)
	Hash alg - unknown(hash 210)
	Pub alg - Reserved for Elliptic Curve(pub 18)
	Key ID - 0xB26548F6A8EE1E82
	Next packet - other than one pass signature
Old: Reserved(tag 0)(23890 bytes)
pgpdump: unexpected end of file.

On the other hand gpg lists the key as follows:

$ gpg --list-packets bc.sec 
# off=0 ctb=95 tag=5 hlen=3 plen=938
:secret key packet:
	version 4, algo 1, created 1526367589, expires 0
	pkey[0]: [2048 bits]
	pkey[1]: [17 bits]
	skey[2]: [2043 bits]
	skey[3]: [1024 bits]
	skey[4]: [1024 bits]
	skey[5]: [1022 bits]
	checksum: 7f2a
	keyid: 8E3DBA0EC4DCC3B7
# off=941 ctb=b4 tag=13 hlen=2 plen=25
:user ID packet: "xmpp:[email protected]"
# off=968 ctb=89 tag=2 hlen=3 plen=308
:signature packet: algo 1, keyid 8E3DBA0EC4DCC3B7
	version 4, created 1526367589, md5len 0, sigclass 0x13
	digest algo 8, begin of digest ef 56
	hashed subpkt 2 len 4 (sig created 2018-05-15)
	critical hashed subpkt 27 len 1 (key flags: 2F)
	critical hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
	critical hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
	critical hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
	critical hashed subpkt 30 len 1 (features: 01)
	subpkt 16 len 8 (issuer key ID 8E3DBA0EC4DCC3B7)
	data: [2047 bits]

Most importantly note the differing key id. Do you have any idea what's going on?

git release tags (missing tag 0.29)

Hey,

please can you synchronize your git tags with your released versions?
At your homepage you offer a 0.29 tarball, it would be great if you can tag the git commit for that version so i can pull a tarball from github and also have proper upstream watches so i gen notifications when new tags are pushed.

Thank you very much,
sincerely,
Levente

Please add support for subpkt 34 and more (4880bis, GnuPG 2.3)

Hello,

GnuPG 2.3, released a few weeks ago, started implementing some bits of
RFC4880bis. Can you add these features in pgpdump as well?

Reproducer:

#!/bin/sh

set -e

TEMPDIR="$(mktemp --directory --tmpdir "keygen.$$.XXXXX")"
trap "cd / ; rm -rf \"$TEMPDIR\"" EXIT
KEYFILE="$TEMPDIR/keyfile"

export GNUPGHOME="$TEMPDIR"
chmod 700 "$TEMPDIR"

gpg --batch --debug-quick-random --quick-gen-key --passphrase '' \
    genkey-test RSA encrypt 0

gpg --export-secret-keys >"$KEYFILE"
gpg --list-packets <"$KEYFILE"
pgpdump "$KEYFILE"

exit 0

Part of the --list-packets output:

    hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
    hashed subpkt 34 len 2 (pref-aead-algos: 2 1)
    hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)

Related pgpdump output:

    Hashed Sub: preferred symmetric algorithms(sub 11)(4 bytes)
            Sym alg - AES with 256-bit key(sym 9)
            Sym alg - AES with 192-bit key(sym 8)
            Sym alg - AES with 128-bit key(sym 7)
            Sym alg - Triple-DES(sym 2)
    Hashed Sub: unknown(sub 34)(2 bytes)
    Hashed Sub: preferred hash algorithms(sub 21)(5 bytes)
            Hash alg - SHA512(hash 10)
            Hash alg - SHA384(hash 9)
            Hash alg - SHA256(hash 8)
            Hash alg - SHA224(hash 11)
            Hash alg - SHA1(hash 2)

Kind regards,