[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: processing of "speculative" key ids: MAY -> SHOULD¦MUST



sen_ml@eccosys.com wrote on Thu, 20 Jan 2000 00:56:26 +0900:

 >  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.
 >
 >i think the use of MAY here seriously undermines the usefulness of the
 >"speculative" key id.  i think it would be better if implementations
 >SHOULD (or even better MUST) process "speculative" key ids.

I vote for staying with the current wording. The suggested change
might be only a small overhead for a program like PGP or GnuPG,
but the change (especially with a "MUST") creates a major
performance penalty for "wrapper" programs in mail-servers.

One of my programs is a mail-server with automatic
encryption/decryption. To avoid having to "re-invent the wheel",
I use PGP resp. GnuPG (depending on the customer's wishes) for
the actual en-/decryption.

To be able to do automatic decryption of incoming mails, the
mail-server "knows" all secret key ids and their PGP passwords
(stored in secure memory, of course). It scans the incoming mail
for the recipient ids and then calls PGP/GnuPG with the
appropriate password for the actual decryption.

If zero key ids become obligatory, it has to test all keys on the
secret key ring (potentially containing a _lot_ of keys for a
major city administration). While this testing might be an
acceptable overhead for PGP/GnuPG, it is a much bigger overhead
for the "wrapper application" which can only test 1 key per
PGP/GnuPG call.

Speculative key ids are only helpful when used together with
nym-servers (as otherwise the mail headers would permit the
traffic analysis that the sender wants to avoid). Using
nym-servers in a proper way, however, can avoid traffic analysis
even with "normal key ids". So the "speculative key id" feature
does not really gain anything new.

Therefore, let us not create performance penalties to gain "just
another way of doing something we could have done already all
along".

- Wolfgang Redtenbacher

---------------------------------------------------------------------
Redtenbacher Software                Tel.:   +49 7159 17046
Roemerstr. 11/1                      Fax:    +49 7159 17047
D-71272 Renningen                    e-mail: wolfgang@redtenbacher.de
---------------------------------------------------------------------