GnuPG feature request: Step-wise decryption
abognupg at redtenbacher.de
abognupg at redtenbacher.de
Fri Feb 27 22:30:24 CET 2004
Hi,
I use GnuPG in a mail gateway scenario that has to interoperate with
many different "PGP-like" products that are, unfortunately, not fully
RFC 2440 conforming.
On the sending side, I can fix any problems by doing the signing +
encryption in steps (using "--store", "-z 0" and "--no-literal" in a
similar way than the one described for PGP 2.x on the GnuPG website).
Thus the 3 layers (innermost: literal packet and any signature
packets; middle layer: compression packet; outer layer: pub key
encrypted session key + symmetrically encrypted data) can be produced
in a controlled way, and little utility programs permit me to do any
needed packet re-sorting and/or packet header re-writing without
having to re-invent GnuPG core functionality like compress/uncompress
or encrypt/decrypt.
However, on the receiving side, currently there is no such user
control over the GnuPG decryption/verify process. It would be great to
have options like "--stop-after-decryption" and
"--stop-after-uncompress" (these names are just examples, of course)
that cause GnuPG to only do the first and/or the second of the 3
decryption/verify steps (decryption, uncompress, signature
verification) and output the result as a binary OpenPGP data
structure.
This would permit "compatibility plug-ins" (in the form of scripts
and/or utility programs) for "PGP-like" crypto products (e.g.
"CryptoEx" has a very unusual way of interpreting RFC 2440, to say the
least), without GnuPG needing individual adjustments for every quirk
that is found in other "PGP-like" programs.
- Wolfgang Redtenbacher
PS: I am willing, of course, to contribute the utility programs which
I developed for interoperability fixups to an open source pool, so
that any "interoperability plugin" has only to be researched,
tested and developed once for a "PGP like" crypto product.
More information about the Gnupg-devel
mailing list