[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rest of World encryption hardware products?

	 >
	 >I read the whitepaper on the site.  It contains a number of phrases
	 >which should set off any crypto expert's snake-oil detectors, the mos
	t
	 >crucial being "virtual one time pad".
	 >
	 
	 I don't think you need to take quotes out of context and change
	 their wording.  Here's exactly what was written.
	 
	 "With RKS, a Random KeyStream derived from a physical random 
	 number generator is used as the cipher key.  Conforming to the 
	 requirements for a practical Vernam Cipher, the Random KeyStream
	 is the same length as the message and will not repeat with a 
	 small statistical probability. The secret is the effective 
	 management of a virtual keystream over 10³º bytes long."
	 
	 It is not claiming to be perfect, there is a small statistical
	 probability of a repetition.  Obviously you can't store a 10^30
	 byte 1-time pad.  So it has to be generated from a smaller
	 amount of random data.  However the solution is elegant and
	 has been reviewed by some top cryptographers, like Bart Preneel
	 and Fred Piper.  So far it has held up under tough analysis,
	 including by some cryptographers over at Bell Labs. It's 
	 effective key strength is 128 bits.

Your own excerpts prove Bill's point.  The web page is full of statements
about how the Vernam cipher is theoretically unbreakable.  But a Vernam
cipher requires a *true* random key stream as long as the message.  It
is *not* a cipher where you XOR the message with a pseudo-random key stream.
But that's precisely what this cipher is doing -- you say so, in about
those words.  This is an ordinary stream cipher, not a one-time pad.

I have no intrinsic objection to stream ciphers, though using them
properly requires a great deal of care.  I have serious objections to
misleading advertising.
	 
	 >It also has built-in key recovery, and appears to require interaction
	 >with a centralized network service for all encryption and decryption.
	 >As described, it also has good potential to have severe scaling
	 >problems.
	 >
	 
	 The built in key recovery is why the unrestricted export license was 
	 granted.  No keys are escrowed with the government or third party 
	 agencies (unlike TIS's solution).  This is very powerful stuff.  Any 
	 company in the world, except for places like Iraq, can buy the system
	 and keep their keys to themselves.  Key recovery is at their own 
	 discretion, not forced upon them by the US government.

I'm not certain how this works.  But let me shoot down a strawman.

Suppose that this system did indeed use a true one-time pad.  A customer
would be shipped N copies of a CD-ROM of true-random bits -- about 4800M
of them.  The purpose of the server, then, would be to allocate chunks
of the bitstream to clients, ensuring that no portion was ever reused
(remember Venona?).

Such a system would be a theoretician's delight and a practical nightmare.

The problem is that you have to maintain perfect security on *every*
copy of the CD-ROM.  If one of the N is stolen (or the machine with it
hacked), all past, present, and future conversations are compromised.
And the probability of that happening is exponential in N.  In other
words, it doesn't scale at all.

It's also obvious that 4800 Mbits doesn't last very long -- less than
an hour at T-1 speeds.  So you'd have to switch CD-ROMs -- simultaneously;
everyone needs to be playing off the same score -- and safeguard all of
the old CD-ROMs as well.

Key recovery, of course, is simple in such a scheme:  you turn over
the CD-ROM to the government on demand.

In all seriousness, DES in OFB mode is likely to be more secure in
practice.  IDEA or CAST-128 in OFB mode would be even better; they
have a key size of 128 bits.

Of course, this scheme is clearly not a true one-time-pad.  The real
question is how the key stream is generated from the keying material.
Is it a published algorithm?  If not, I'm very unlikely to trust it
even if the Web page were not misleading.
	 
	 As for scaling, I guess if you can exceed 2 thousand requests per serv
	er
	 per second, then you've got a problem.  It ships as a dual server 
	 system.  This sure beats the hell out of Public Key implementations 
	 which can't do more than 10 per sec.

10 per second *per machine communicating*.  And public key systems can
set up a secure channel even if the KDC is unreachable; this scheme can't.
Follow-Ups: