[1318] in cryptography@c2.net mail archive
Re: Using satellite feeds to get shared pseudorandom numbers ]
daemon@ATHENA.MIT.EDU (John Kelsey)
Mon Aug 11 15:14:23 1997
To: "Perry's crypto list" <cryptography@c2.net>,
Richard Pinch <rgep@cam.ac.uk>
From: John Kelsey <kelsey@plnet.net>
Date: Sun, 10 Aug 97 13:50:28 CDT
[ To: Richard Pinch, sci.crypt, Perry's Crypto List ##
Date: 08/08/97 10:20 pm ##
Subject: Re: Using satellite feeds to get shared pseudorandom numbers ]
>Subject: Re: Using satellite feeds to get shared pseudorandom numbers
>From: Richard Pinch <rgep@cam.ac.uk>
>Sender: rgep@rgep.quns.cam.ac.uk
>Date: Mon, 04 Aug 1997 10:32:22 +0100
>> 1. Alice and Bob agree on a starting time T, an unpredictable
>> digital channel C, and a crunch factor, Z. This is all open,
>> since there's no way for either of them to take advantage of
>> this.
>>
>> 2. Alice chooses a 160-bit random number, R_0, and sends
>> hash(R_0) to Bob.
>>
>> 3. Bob chooses a 160-bit random number, R_1, and sends R_1 to
>> Alice.
>>
>> 4. Alice and Bob both generate a shared triple-DES key, K_*,
>> from R_0 XOR R_1, hash(R_0,R_1), etc.
>>
>> 5. At time T, they both start listening to channel C. They
>> encrypt the bit stream under K_* in CBC mode, using triple-DES.
>>
>> 6. They apply the crunch factor Z by XORing each Z blocks of
>> ciphertext together to get one block of pseudorandom output.
>>
>> 7. They use these pseudorandom outputs as needed.
>This sounds very similar to a proposal by Chris Mitchell at the
>last IMA Cirencester meeting, December '95. See his article in
>the proceedings, Cryptography and Coding, ed. Colin Boyd,
>Springer Lecture Notes in Computer Science 1025, pp. 84--93.
>In that proposal, the parties select bits at random from a very
>long stream such as a satellite feed. They then reveal in public
>where the bits they have chosen came in the stream and use the
>ones that they have in common. An eavesdropper would need to
>have the whole stream stored to make use of the public data.
I looked briefly at this article. I think the similarities are
mostly superficial--he's trying to do a very different thing
than I am. I don't expect that the public channel we use is too
large to store, I just expect that its audience is too large to
alter it without Alice and Bob soon finding out. I'm really more
interested in the idea of using a public, widely-seen channel,
so that any attempt to disrupt this channel will have to affect
huge numbers of people, and thus be almost certain to be
detected. The goal here is to save ourselves the need of
carrying out some kind of coin-flipping protocol many times over
a network.
>From some of your comments in sci.crypt, I think you might have
been thinking of what we were doing as more similar than they
really were. For example, my proposal never selects a subset of
bits from the unpredictable streams in any way except by
specifying a starting and ending time to listen.
As an aside, though, I am glad you pointed me at these two
articles. Bruce sent me a copy of this Springer proceedings of
this conference a while back, and I hadn't really looked at any
of the articles in it. This article describes a really neat
idea.
>In your scenario, the parties would need to reveal the bit
>positions irrevocably to prevent cheating, otherwise they could
>simply ignore bits they didn't like and pretend they hadn't
>selected them.
Hmmm. The only bit positions we use are the starting and ending
ones. We also must commit to a channel (or set of channels) to
listen to, and a crunch factor--the number of bits we send into
(say) a hash function to get really unpredictable values out of
relatively structured digital signals. I had intended the first
step in the process, described above, to accomplish this.
However, it would make the design a lot cleaner if I added the
hash of this agreed-upon set of parameters to both messages, and
also included it in the computation of the shared key.
>--
>Richard Pinch Queens' College, Cambridge
>rgep@cam.ac.uk http://www.dpmms.cam.ac.uk/~rgep
--John Kelsey, Counterpane Systems, kelsey@counterpane.com
PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36
--John Kelsey, Counterpane Systems, kelsey@counterpane.com
PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36
