[1310] in cryptography@c2.net mail archive
Re: Useful El Gamal Variant
daemon@ATHENA.MIT.EDU (John Kelsey)
Tue Aug 5 18:11:53 1997
To: "Perry's crypto list" <cryptography@c2.net>
From: John Kelsey <kelsey@plnet.net>
Date: Tue, 05 Aug 97 16:07:20 CDT
-----BEGIN PGP SIGNED MESSAGE-----
[ To: Perry's Crypto List ## Date: 08/05/97 03:26 pm ##
Subject: Re: Useful El Gamal Variant ]
>Subject: Re: Useful El Gamal Variant
>To: kelsey@plnet.net
>From: Hal Finney <hal@rain.org>
>Date: Sun, 3 Aug 1997 16:55:28 -0700
>John, what is the purpose of the check block C in the protocol?
>Is there a weakness if it is left out? I may be missing
>something, but the only purpose I have been able to figure out
>is so that all recipients can check that the message is
>encrypted with the same K[*]. But it doesn't seem too likely
>that the message would be encrypted to one person with one K[*]
>and to another person with a different K'[*], since the message
>would not have a plausible decryption under two different keys.
On general principle, I didn't want it to be possible for an
attacker to alter the DHKX block without being detected. This
protects from chosen-ciphertext related-key attacks, though
these shouldn't work anyway.
>Is this mostly a key-recovery feature, so that the government
>can guarantee that they have access to the same decryption key
>the other recipients are getting?
Nope. There's no way to be certain what is in any other
recipient's encrypted key blob. If you all use the check block,
then each of you who accepts the encrypted key you received got
the same key, but this is a very different thing. The check
block also lets you cheaply determine whether you're an intended
recipient. My original idea for this was for a (user-oriented,
not government-oriented) key recovery mechanism, in which I want
to encrypt to (say) 20 trustees, with a 15/20 secret sharing
scheme. One nice thing that dropped out of it, as pointed out
by David Wagner, is that there is no way to know who the
recipients of this note are by looking at it. That might make
this format useful for a kind-of token-ring based anonymous
network (as discussed before by Carl Ellison), where you send
the token around, and it may contain messages from none, some,
or all the members of the ring. An outsider can't tell a thing
about this; an insider who doesn't receive the message can tell
only that he didn't receive it, not who else did. In fact, we
could even design this so that the encrypted message wasn't
distinct from the encrypted key blocks; recipients would have to
try each of the possible blocks (many of which would usually be
ciphertext). This would make the recipient-checking slow, in
exchange for hiding even the number of possible recipients,
though this information would still leak statistically unless we
always used random padding and kept the total encrypted packet
size constant.
>Thanks,
>Hal
--John Kelsey, Counterpane Systems, kelsey@counterpane.com
PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBM+eUA0Hx57Ag8goBAQGi7AP+KUe/FcO7bPsBzVyZXYTjZA33ukH9ei6d
TwrbKBfcRcqgeDLWkaQuyjdMlTxr/aWspKW4pSjgX0v5fUEtxCD4V35171Zajnyr
4liDpqohYudMoldHvt1vcoljKC2O/DWFH3XHCm8n0lSmRrdBgqKDEEYZho185EFj
aF6xEZ5O/pU=
=G2Z/
-----END PGP SIGNATURE-----
--John Kelsey, Counterpane Systems, kelsey@counterpane.com
PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36
