NODE 40ba6d52Call for Discussion - Time-Delay Protocol
project_31@alias.cyberpass.netWed, 23 Oct 1996 01:47:24 -0700 (PDT)
[Though I have posted this to the group four previous times, I have not
seen it - or any replies to it - in my incoming cypherpunks list
traffic. If you have, sorry for the redundancy. I need a replies to
this within the next week or it will be too late. Thanks...]
%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%
I should be pleased to have informed input on this hypothetical problem:
*
Very simply put, it is desired to put an encrypted, paragraph-length
message into ubiquitous public distribution, contained in an explanatory
plaintext.
On a predetermined date stated in the plaintext, the passphrase is to be
released and the parties holding the message may decrypt the cyphertext
and know its contents.
An undetermined number of persons and organizations would have a high
pecuniary and reputational interest in...
1. Knowing the contents of the encrypted message before the
passphrase is publically released.
2. Counterfeiting both the explanatory message and enclosed
cyphertext to include their own content, then placing the
spoofed message into wide distribution as genuine, or
flooding the net with multiple spoofs.
3. Discrediting the message by attacks on its protocol
integrity in terms of date of release, modification after
stated date of release and any other valid (or invalid)
objections that may occur to them.
It is assumed that these persons and interests do not have access to
NSA-grade cryptanalysis, but may have access to academic-grade
cryptanalysis.
*
At first glance, this seems to be a classic case for PGP using the
following protocol:
1. A large-modulus PGP public key is prepared prior to the
experiment and placed on (a) the keyservers and (b) at an
"authenticating" website of neutral interest and good
reputation.
2. The critical message is encrypted conventionally (IDEA) in
ASCII format with a large passphrase and included in the
explanatory plaintext, which also includes the
authenticating key ID hexnumber and fingerprint, and
instructions on how to obtain the authenticating key.
3. The entire plaintext message is clearsigned with the
authenticating public key, and the resulting textfile is
widely distributed.
This permits the maximum number of persons with trivial interest to
easily decrypt the saved message by simple PGP use of the passphrase
released, and still provides for definitive authentication by those
troubling themselves to obtain the original public key.
*
CALL FOR COMMENTS:
1. How may this protocol be improved?
2. What are the security flaws in this protocol?
3. May this protocol be simplified without compromising
security?
Thanks to all who contribute.
NODE 54277f82Re: Call for Discussion - Time-Delay Protocol
Adam Back <aba@dcs.ex.ac.uk>Wed, 23 Oct 1996 15:05:50 -0700 (PDT)
<project_31@alias.cyberpass.net> writes:
> [Though I have posted this to the group four previous times, I have not
> seen it - or any replies to it - in my incoming cypherpunks list
Not seen it either.
> Very simply put, it is desired to put an encrypted, paragraph-length
> message into ubiquitous public distribution, contained in an explanatory
> plaintext.
>
> On a predetermined date stated in the plaintext, the passphrase is to be
> released and the parties holding the message may decrypt the cyphertext
> and know its contents.
>
> An undetermined number of persons and organizations would have a high
> pecuniary and reputational interest in...
>
> 1. Knowing the contents of the encrypted message before the
> passphrase is publically released.
2048 bit PGP signatory key, long passphrase conventional encryption.
If you are doubtful of the entropy of the passphrase you could encrypt
with a second PGP public key signed by the first, and simply reveal
the secret key.
Post the message to cypherpunks via a nice long chain of mixmaster
remailers. (Then you can't be coerced into releasing the key early).
> 2. Counterfeiting both the explanatory message and enclosed
> cyphertext to include their own content, then placing the
> spoofed message into wide distribution as genuine, or
> flooding the net with multiple spoofs.
Spoofing is difficult to prevent because anyone can repeat what you
are doing, publish a key, publish the explanatory text and encrypted
message, then post the decrypt key later.
> 3. Discrediting the message by attacks on its protocol
> integrity in terms of date of release, modification after
> stated date of release and any other valid (or invalid)
> objections that may occur to them.
With Tim May's BlackNet key, there were several after the fact
attempted spoofs of it, people publishing other keys with "BlackNet"
as the key id, as a kind of denial of service attack.
Getting a timestamp from a PGP timestamping service on the key, and
also having the encrypted message and explanatory text timestamped
before releasing it would help. Then people couldn't spoof unless
they knew before hand what kind of topic your release would be about,
so that they could pre-sign a selection to pick from as a spoof.
Adam
--
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`