New York Times story

[Ken Brown]

If this is the case, then the true key in this application is not the
one extracted from the random data stream, but the "exact marker to
begin intercepting that stream" which needs to be exchanged and stored.

The same flaw as all the other schemes to implement OTP without actually
copying the pad. The secret a third party needs to know is not the
contents of the pad but the method used to generate the pad. And if that
secret is easier to work out than the pad then the scheme is weakened,
if it is harder, then it will contain more random data than the pad, so
why not just exchange the whole pad in the first place?

Ken Brown

David Howe wrote:
> 
> Just received. I pass it on for what its worth but have not as yet been
> able to access the story on the web.
> >The Key Vanishes: Scientist Outlines Unbreakable Code
> >
> >By GINA KOLATA
> >
> >computer science professor at Harvard says he has found a way to
> >send coded messages that cannot be deciphered, even by an
> >all-powerful adversary with unlimited computing power. And, he says,
> >he can prove it.
> >
> >http://www.nytimes.com/2001/02/20/science/20CODE.html
> >
> >
> >
> >For archives see: http://www.interesting-people.org/
> 
> It's an interesting (but not entirely secure) variant on One Time Pad.
> Basically, you have a single data source (he specifies a orbital satelite)
> outputting a true-random stream, presumably intermixed with some sort of
> timing / interlock counter
> Both users somehow agree (method not discussed) an exact marker to begin
> intercepting that stream; they sample a slice from the stream to give them
> their symmetric key, and store it.
> Symmetric OTP encryption is used to encrypt the message, which is then
> transferred, and decrypted with the stored stream (which is then discarded)
> Security relies on a high (but reliable) data rate from a true-random data
> source forming too big a mass of data to be usefully stored (I think it
> envisions intervals between sync-acceptance, intercept of keydata, and
> actual sending of data measured in hours, with *very* large amounts of
> non-compressable data being transmitted in that time period, so as to
> conceal the actual key used in a pool that, if not physically beyond
> storage, would take too long to process and extract a message from the key
> material and encrypted data.
> 
> I doubt it would be practical - the data source would almost certainly be
> possible to replace with a pseudo-random stream, thus reducing it to a much
> simpler problem (there is no way I can think of to secure the receivers from
> a closer, stronger signal overriding the orbital stream; I am sure you can
> envision a suitable transmission device that could hit a city-sized
> footprint with your own datastream if you needed to; two of them would allow
> the message to get though regardless of the deception; one would allow the
> message to be decrypted by the black hats, even though the recipient failed
> to correctly do so (and that would probably be written off as corruption in
> transmission of either data stream or message); this is not to mention the
> value of an agent managing to switch the true-random generator "core" to one
> that can be switched amongst a choice of prngs... or replace the satellite
> with such a "gimmicked" one if usage the system took off.