Mailing List Archive

GNUPG 0.3.2 encryption bug
I create a file with "dd if=/dev/zero of=test bs=1k count=2000" (nice empty
test file).
I encrypt it using password "abcd" using the command "gpg -z0 -c test".

I then try and decrypt it using the command "gpg -d test.gpg > t" and get the
following output:
gpg (GNUPG) 0.3.2; Copyright (C) 1998 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

gpg: Warning: using insecure memory!
gpg: Problem reading source (1 bytes remaining)
gpg: handle plaintext failed: File read error
gpg: packet(1) with unknown version 255
gpg: public key decryption failed: Unknown pubkey algorithm
Segmentation fault (core dumped)

Here's the output of "ls -al" on the directory:
total 6233
drwxrwxr-x 2 rjc staff 1024 Aug 23 01:53 .
drwx------ 24 rjc root 1024 Aug 23 01:49 ..
-rw------- 1 rjc staff 212992 Aug 23 01:50 core
-rw-rw-r-- 1 rjc staff 2043904 Aug 23 01:50 t
-rw-rw-r-- 1 rjc staff 2048000 Aug 23 01:28 test
-rw-rw-r-- 1 rjc staff 2048083 Aug 23 01:29 test.gpg


This is a test case of a bug that caused me problems when trying to compress
some large bzip2 archives (I don't want compression as the files are
already compressed and it won't gain me anything).

Copies of all the files in that directory are available on demand (including
the core file). The gpg program comes from version 0.3.2-1 Debian package.

Russell Coker

PS I get hit by a slightly different bug when I try to use compression, but
it's harder for me to devise a test case for it.
Re: GNUPG 0.3.2 encryption bug [ In reply to ]
bofh@coker.com.au writes:
> I create a file with "dd if=/dev/zero of=test bs=1k count=2000" (nice empty
> test file).
> I encrypt it using password "abcd" using the command "gpg -z0 -c test".

I get the same bug with gpg-0.3.4, on linux-ppc and linux-i386. A 20k file
will cause it, but not a 2k file. I get the bug with compression turned on
too. It doesn't actually cause my gpg to coredump, but certainly fails to
decrypt:

278:warner@mongo% dd if=/dev/zero of=test bs=1k count=20
20+0 records in
20+0 records out
279:warner@mongo% gpg -z0 -c test
gpg (GNUPG) 0.3.4; Copyright (C) 1998 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

280:warner@mongo% gpg -d test.gpg > t
gpg (GNUPG) 0.3.4; Copyright (C) 1998 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

gpg: Problem reading source (3 bytes remaining)
gpg: handle plaintext failed: File read error
gpg: [don't know]: invalid packet (ctb=33)
281:warner@mongo%


Could there be something wrong with the way that lengths are encoded that
doesn't show up for small files?

-Brian
warner@lothar.com
Re: GNUPG 0.3.2 encryption bug [ In reply to ]
Brian Warner <warner@lothar.com> writes:

> I get the same bug with gpg-0.3.4, on linux-ppc and linux-i386. A 20k file
> will cause it, but not a 2k file. I get the bug with compression turned on
> too. It doesn't actually cause my gpg to coredump, but certainly fails to

I think I have introduced a bug in the buffer logic - the interanl
buffers are 8k so ...


Werner
Re: GNUPG 0.3.2 encryption bug [ In reply to ]
Werner Koch <wk@isil.d.shuttle.de> writes:

> I think I have introduced a bug in the buffer logic - the interanl
> buffers are 8k so ...

Okay, I found the bug. I has to do with the new 4 byte length
headers. Fixed.

BTW: This might be the reason why pgp 5 can not decrypt some messages:
The 4 byte length headers are OpenPGP but to new for pgp5 - Can
someone please check, which version of pgp knows about it?



Werner
Re: GNUPG 0.3.2 encryption bug [ In reply to ]
wk@isil.d.shuttle.de (Werner Koch) writes:
> Werner Koch <wk@isil.d.shuttle.de> writes:
>
> > I think I have introduced a bug in the buffer logic - the interanl
> > buffers are 8k so ...
>
> Okay, I found the bug. I has to do with the new 4 byte length
> headers. Fixed.
>
> BTW: This might be the reason why pgp 5 can not decrypt some messages:
> The 4 byte length headers are OpenPGP but to new for pgp5 - Can
> someone please check, which version of pgp knows about it?

pgp50i looks like it doesn't understand the 4-byte length headers.
src/lib/pgp/pgpPktByte.h suggests that it understands two cases for the
length bytes of "terminating subpackets":

length < 192: one byte '0sssssss' or '10ssssss'
192 <= length < 8384: two bytes '110sssss ssssssss'

src/lib/pgp/pipe/parser/pgpPrsBin.c has a comment that mentions the original
PGP packet format (1/2/4/0 bytes of length field specified by the ctb byte)
and the "one-pass PGP 3 format" with multiple non-final subpackets, each with
2^s bytes (s is [0 .. 32]) and a final subpacket with s <= 8383 bytes. There
isn't mention of a format in which the 1/2/4(5) bytes of length are indicated
by the upper-order bits of the first length byte (which is what I believe GPG
and the OpenPGP draft use). (is it just me, or is this length representation
inspired by drugs? Use an 8-byte field and never think about it again. Ever).

pgp55pi seems to be the same way.

I don't have a copy of pgp60, but I hear that it's available in england
somewhere :).

-Brian