From: project_31@alias.cyberpass.net
To: cypherpunks@toad.com
Message Hash: 40ba6d52256f77988d5a812b245220137cf09d998a7e9f153a35a6722113d059
Message ID: <199610230807.BAA14932@sirius.infonex.com>
Reply To: N/A
UTC Datetime: 1996-10-23 08:47:24 UTC
Raw Date: Wed, 23 Oct 1996 01:47:24 -0700 (PDT)
From: project_31@alias.cyberpass.net
Date: Wed, 23 Oct 1996 01:47:24 -0700 (PDT)
To: cypherpunks@toad.com
Subject: Call for Discussion - Time-Delay Protocol
Message-ID: <199610230807.BAA14932@sirius.infonex.com>
MIME-Version: 1.0
Content-Type: text/plain
[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.
Return to October 1996
Return to “project_31@alias.cyberpass.net”