I just got a message from a human rights activist, who pointed out a
shortcoming of PGP for -- for the lack of a better word -- paranoid
conspirators.
Imagine, that a conspiracy expects to be infiltrated. They send encrypted
messages back and forth but they have a dilemma: to sign or not to sign? If
they do sign, the infiltrator will have damning evidence on his hands and
the bad guys will be able to crack down on the conspirators. If they don't
sign, the infiltrator will be able to forge messages and thus seriously
interfere with the activities of the group (e.g. call off action in the name
of the ringleader, etc.).
Now, there exists a cryptographic solution for this problem, moreover,
RFC2440 even hints that it might be implemented in OpenPGP, though I have never
seen it used: X9.42 Diffie-Hellman key agreement (see also RFC2630, RFC2631
and RFC2633).
In addition to signature and encryption keys, one can have a DH subkey
which may be used to create a (salted) two-party shared secret session key
and send an MDC-protected encnrypted message using that key. Now, the
receiving party can be sure that it was composed by the sender, but has no
means of proving it to a third party. The sender can plausibly deny
authorship, claiming that the receiver has forged it using his private key
and the sender's public key.
Has anybody ever bothered implementing (or even designing an implementation
of) this in an OpenPGP-friendly manner? Seems like it's just a matter of a
third ESK type (tentatively called DH-ESK) and a clear definiton of DH keys
(for which we have reserved identifier 21), which, I guess, should be
identical to ElGamal keys, though it is instrumental that the entie
conspiracy used the same modulus and generator element.
DH-ESK should be very similar to SK-ESK with a salted (but not iterated)
S2K, except for the additional 8-octet IDs of the sender's and the
recipient's public DH keys. The usual traffic-analysis thwarting techniques
of leaving one or both of them blank obviously apply. Allowing for an
ephemeral sender PK to be included is pointless, as that would bring us back
to ElGamal encryption (well, almost), for which there is already a PK-ESK.
If the MDC verification works out on the receiving end, the implementation
should show the message as being "sealed" by the sender on the date from the
literal packet, in addition to decrypting it, much like it handles
signed+encrypted messages.
It's so easy and straightforward that I'd dare to propose it for 2440bis.
--
Daniel