comparison gpg:pgp6.5.1

[sen_ml@eccosys.com]

  i know that gpg can handle (and generate) messages w/ the following
type of keyids (rfc 2440 section 5.1):

    An implementation MAY accept or use a Key ID of zero as a "wild card"
    or "speculative" Key ID. In this case, the receiving implementation
    would try all available private keys, checking for a valid decrypted
    session key. This format helps reduce traffic analysis of messages.

  is there a version of pgp that can correctly handle this type of
keyid?  the few versions i have tried ignore such keyids, so if all
keyids in a message are of the above type, decryption fails.  i am
guessing that the tested versions fail based on tests i have conducted
w/ messages that contain both "speculative" and normal key ids.

  it's very nice that gpg can handle this.  it would be even nicer if
other rfc 2440 implementations handled it as well (it really shouldn't
be hard to add this support).  until (i can dream, can't i?) support
is added, it would be nice if gpg was able to leave in keyids for
specifically those users of rfc 2440 implementations that don't
support the "speculative" key id.  then even if a message is
intercepted and the keyids extracted, the only keyids that are
available to an attacker are those for people who use software that
doesn't support "speculative" key ids.

  as an example of one place this functionality would be useful,
consider the idea of a mailing list that has a rfc 2440 keypair for
itself and public keys for all subscribers (so posts to the list can
be encrypted using the public key of the list, the list decrypts
incoming messages and re-encrypts w/ subscriber public-keys, etc.)
implemented naively, you might end up w/ each encrypted message from
the list containing keyids for all of the subscribers.  this is
undesirable in certain types of situations.  (yes, you could encrypt
to each subscriber separately and send messages out that way too, but
the keyid would still be visible -- also, let's not get into the
mail address of the subscriber being in the envelope/headers --
that's what anonymous remailers can be used for)

  iirc, werner has said in the past that he doesn't consider this
something that he wants to add to gpg at this point (there are higher
priority items).  he said it would be easy to write a separate tool to
selectively remove certain keyids from a previously prepared rfc 2440
message (it should be easy because all you are doing is locating
certain bytes and zeroing them!).  

  i agree it would be easy to write -- but it's so much easier to
write it if you can use a library for handling rfc 2440, and that is
not something that is available yet (iirc, i would love to be wrong
about this).

  btw, in the opinions of those of this list, would such a tool be
considered "cryptographic" software?  it doesn't seem like it should
be to me.

  anyway, to return to the original point, i think support for
"speculative" key ids is a nice thing that gpg has and that pgp
doesn't seem to.