gpg problems with --verify
Ted Deppner
ted at jasmine.psyber.com
Wed Jan 26 01:04:37 CET 2000
First, let me say that I have reviewed the FAQ, docs, and mailing list
archives for Dec 1999 and Jan 2000 on gnupg-users and gnupg-devel, and have
found nothing of relevance to the issues below. Please be kind if I've
missed something obvious.
The first problem is that --verify doesn't always complain when there are
extra options on the command line. This can lead to gnupg 'misrepresenting'
information to the user in the case of a detached signature that isn't
really a detached signature. This in effect renders detached signings
cryptographically useless unless the user also does --list-packets and
understands the output.
For instance:
gpg --verify file.tgz.asc file.tgz
where file.tgz.asc is a --signed file (not --detach-signed) of very small
size, small enough to look like a normal detached sign. Gnupg happily
verifies the contents of file.tgz.asc has a good signature, and then stops
processing, and does not complain about file.tgz still being on it's cmd
line.
Thus, a user could be lead to believe that file.tgz is --detach-signed as
evidenced by --signed file.tgz.asc returning a GOOD signature, when, in fact,
the file.tgz has not even been looked at.
Obvously a malicious deception can be brought about here... consider taking
a valid signing of a small file, sticking it in a .asc, and then including
a trojaned .tgz file with it. Assuming the size of the .asc is small enough,
most people wouldn't even cat the .asc, meaning even a valid signed usenet
posting could pass as the .asc for the tojan.
A step up would be tweaking with the gnupg message format, ascii armoring
the originally signed document, tacking the signing packet on it, thus
rendering the casual catting of the file useless. A --list-packets gets
around this of course, but the user must then understand that output...
Second, the man page states that for --verify reads:
--verify [[sigfile] [signed-files]]
leading me to belive that:
gpg --detach-sign --armor file1.tgz file2.tgz file3.tgz
would create a signature for the "combination" of the files.
Indeed it does. However, it's not clear what really happened. Gnupg
concatenated the files together for purposes of hashing, and then signed
the resulting hash, as expected.
However, the expected command line to --verify does not work:
gpg --verify file3.tgz.asc file1.tgz file2.tgz file3.tgz
Unfortunatly, --verify compares file3.tgz.asc only against file1.tgz,
resulting in a BAD signature notice. As noted earlier, file2.tgz and
file3.tgz still being on the cmd line isn't brought to the user's attention.
To actually test the signing, we must:
cat file1.tgz file2.tgz file3.tgz > tmp.tgz
gpg --verify file3.tgz tmp.tgz
and then we we the GOOD signature notice.
While this particular use of signing and verifying is probably not
mainstream and can be subject "this is tricky" notice in the man page, that
notice isn't currently to be found.
More importantly, the use of the two seemingly complimentary options
(--detach-sign and --verify) isn't complimentary in interpretation or
usage, which will only lead to user confusion and a weaking of the overall
usefulness of security.
I would prefer a note during a --sign operation where multiple files are
listed that the signing is of the concatenation of the files, and naming
the resulting .sig or .asc to some name other than that of the last file in
the file list, or perhaps sending it only to stdout.
This is my first posting into any GNU project, and I've tried to double check
my assumptions and make sure I don't screw anything up. If I've missed
something, please let me know. I can test things or provide more detail as
needed.
Thank you.
Version Information:
I'm running Debian unstable (potato / woody) on a Celeron 333.
ii gnupg 1.0.1-2 GNU privacy guard - a free PGP replacement.
ted at dondra:~$ gpg --version
gpg (GnuPG) 1.0.1
Copyright (C) 1999 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.
Home: ~/.gnupg
Supported algorithms:
Cipher: 3DES, CAST5, BLOWFISH, TWOFISH
Pubkey: ELG-E, DSA, ELG
Hash: MD5, SHA1, RIPEMD160
--
Ted Deppner
ted at psyber.com
http://www.psyber.com
More information about the Gnupg-devel
mailing list