The Key Vanishes: Scientist Outlines Unbreakable Code

[Tom]

An Metet wrote:
> 
> By GINA KOLATA
> 
>         http://www.nytimes.com/2001/02/20/science/20CODE.html?pagewanted=all
> 

essentially, a one-time-pad with a central source of randomness, the key
being the point in the random-number-stream that you start with.


> "It's a cute idea, but it's simply unmanageable," Dr. Deavours said.

I agree completely on that, but for very different reasons.

a) ok, it *is* unbreakable, since it's a one-time-pad. however, that
only refers to mathematics/cryptoanalysis, not to the wide variety of
other attacks.


b)
> He explained: "You can still get the message, but maybe not by cryptanalysis. 
> If you're in this business, you go after a reasonably cheap, reliable method. 
> It may be one of the three B's: burglary, bribery or blackmail. Those are right 
> up there along with cryptanalysis in their importance."

of course, that's the first thing coming to mind. however, I have other
reservations:


c) the system's security rests entirely on the fact that the data volume
is so "enormous" (10 mio. mio bits per second).
or is it? high-energy research (CERN, etc.) today generates terrabytes
of data everytime they hit the "on" switch. the computer centres there
are equipped to handle two-digit terrabyte volumes in very short times.
the problem is that the security of your message increases linear with
the time you wait before sending it, because said time determines the
likeliness that eve has run out of storage space and has started to
overwrite old data.


d) that, however, isn't even the worst problem. since bob also has to
record the stream in order to decrypt the message, alice has to say
"start" at a time X. all eve has to do is also hit the "record"
button.(*)
what this system does protect against is eve finding the message and her
desire to decrypt it AFTER the fact.
but it doesn't offer any advantage over existing systems in this area.
the main danger of them is that either alice or bob store the
one-time-pad or plaintext somewhere. that's a danger entirely outside
the cryptosystem and not dealt with in this one, either.

(*) one might think that no explicit "start" is required, since bob can
just start grabbing the stream "live" while receiving the message.
however, that requires perfect syncrocity(sp?) between alice and bob,
something that is quite impractical at the requested flow rate.
a solution here would be to have the random numbers broadcasted over the
very medium which is used to transport the messages, much like the
cycling in your PC. practical problems of a wide-area useage of this
aside, it would only make it even easier for eve to decrypt the message,
since she receives the key right alongside it. in other words: the whole
encryption business would be a trivial waste of computing power.



if that's not enough:

e) the central source of randomness is sure to be a major target of any
attacker. just by replacing the randomness with a seemingly-random
function that you can easily recreate, eve would save tremendous amounts
of storage space while lulling everyone in the impression of having an
"unbreakable" cipher.