#0x38: nbpg moving forward
Fri, 23 Jul 2010 20:37 GMT+1, gilles@

I had temporarily paused nbpg development because I was facing a bug that I did not have much time to investigate.

Whenever parsing a Compressed Data Packet, nbpg would successfully extract the data but fail to inflate it with a data format error. No matter what I tried, I could not figure out what was wrong with my code or with the data.

Turns out that I had to rely on an undocumented feature of zlib. I discovered it when I gave up at trying to make RFC interpretations and looking at what the GnuPG guys did. I saw the following comment in their compress.c:

* PGP uses a windowsize of 13 bits.
* it forces zlib not to expect a zlib header. This is a
* undocumented feature Peter Gutmann told me about.

After doing a one line diff to nbpg I managed to extract a compress data packet. This allowed me to parse two new packets and I can now move things forward :-)

Output of a signed text file:

### 0x20cd54000: Compressed Data packet
length: 107
algorithm: ZIP
### 0x20cd54800: One-Pass Signature packet
length: 13
version: 3
type: Signature of a binary document
hash algorithm: SHA-1
public-key algorithm: DSA
keyid: F838AC47FA273AD7
nested: no

### 0x20cd55000: Literal Data packet
length: 19
type: binary data
filename: bleh.txt
flags: none
buffer: [test
]

### 0x20cd55c00: Signature packet
length: 70
version: 4
type: Signature of a binary document
public key algorithm: DSA
hash algorithm: SHA-1
size of hashed area: 6
size of unhashed area: 10