Hal Finney wrote:
Thanks to Bill Stewart for some very helpful comments....
5.1 Encrypted Session Key Packet - Traffic Analysis Risk -
The KeyID field, as defined, leads to a major traffic analysis risk,
but the format doesn't depend critically on the value in the field.
At a previous Bay Area Cypherpunks meeting, somebody from PGP
mentioned a request from some freedom fighter users that KeyIDs
be shorter, because the current tyrannical government was
using them to identify who to torture into decrypting messages -
having PGP was incriminating enough, but with short KeyIDs,
e.g. 0-3 or 0-16, it's possible to reduce decryption workload
without indentifying the user of the message.
I raised this possibility on the list a few weeks ago, but the only
response was negative (I think because it would break the way the
keyids were being used as indexes).
If you have that sort of risk, then *any* clues can be used to
incriminate you. 2 bits is enough for torture purposes, in my
admittedly limited experience of the art.
Some obvious alternative implementations are to keep the field
for compatibility, while specifying that the
- - the receiver of a message MAY attempt decryption regardless
of the value in the field, regardless of whether
it's intended for him or not.
- - the sender must output a value in the field that
- -- SHOULD be the KeyID, but
- -- MAY be all-0, for which the receiver SHOULD/MAY decrypt
...
Interesting possibilities. Jon Callas also suggested (internally) the
idea of putting all zeros into the keyid field to mean that the receiver
should try all his keys.
This is a good idea. All zeroes, and when confined to small groups who
all know what is going on, and have the software that understands this,
would work well.
Since this just requires permission in the spec, rather than
needing specific implementation, and since the main negative impact
on non-implementing users is attempting to decrypt
an occasional message that wasn't intended for them that they
happened to receive, I'd like to ask that it be included.
I agree with this. This would be a MAY, would it not?
"An implementation MAY interpret a KeyID of all zeroes to mean that all
keys available should be used to decrypt the message speculatively."
or some such.
I don't think adding any extra features will work for the intended
audience. For reasons that I won't go into now, I don't think any users
who really need the speculative mode will be using anything but pgp2.6
(the C version, not any compatibility suite like Cryptix). The rest of
us might like to implement it for fun.
--
iang systemics.com
FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com