Random #'s via CD-ROM?

Hello cypherpunks (first post):

	In the hopes of starting an cryptograpy-related thread...


	I have been reading the section in _Applied Cryptography_ about
random number generators, and some proposed hardware random number
generators. It seems to me that with the CD-ROM drive becoming
increasingly common these days, this could be exploited as a source of
randomness. For example:

	[1] Read a pseudo-random section from the CD-ROM. Unless you catch
the blank end of a sector, you should obtain random data (this is one
obvious problem with this method).

	[2] Read a pseudo-random section from the CD-ROM, and use this
data to select another chunk of data from the CD-ROM (more random, yet we
still have a problem if we read the blank end of a sector...).

	The two above ideas are okay, but they both suffer from the same
problem, namely if you read the unused portions of the cluster you will
get a random sample of all 0's. Not good.

	The idea that really interests me is this:

	Place an *audio* CD in the CD-ROM drive. Most CD-ROM drives know
about audio discs now, and I believe they can be made to read the binary
waveform data even if they don't understand the Red Book audio format. If
you have something really random/discordant (Ministry / NIN / Curve /
Sonic Youth / Pain Teens / Diamanda Galas / Coil / etc) and you take
samples of the waveform and play with them as described in _AC_, you could
get some pretty random samples.

	Of course, care must be taken to only read within the portions of
the CD/CD-ROM that have actually been encoded....

	What do you all think? I have code to work with CD-ROM drives,
works on my system and a friend's CD-ROM drive as well (for DOS machines).
I don't know about Mac / UNIX CD-ROM drive programming, sorry. =(

	I welcome all comments, criticisms, flames, love letters, etc.
Post if there's wide enough appeal, or just email me.

	[ I am also taking suggestions for random / discordant / loud
music to use with this method. Please email me, don't post, as I'm sure
the rest of the list would dislike us discussing that in public ]

-- 
==========================================================================
| Michael Brandt Handler   |  <grendel@netaxs.com>  |   Philadelphia, PA |
==========================================================================

Michael Brandt Handler says:
> 	[1] Read a pseudo-random section from the CD-ROM. Unless you catch
> the blank end of a sector, you should obtain random data (this is one
> obvious problem with this method).

How do you pick the random section in the first place? Oh, I see, we
use a random number generator!

Ahem.

Its very hard to determine if a pseudrandom number generator is "good
enough" for cryptographic purposes. Many generators that look "good
enough" for doing normal work fail miserably for cryptography. If one
is using, say, a one-time pad, one has a need to generate a large
number of truly random numbers quickly. Hacked up schemes usually
don't cut it when thats the case.

If you only need a few bits, you might as well use a non-deterministic
process outside of the program's control, like a user tapping a key.
However, for work requiring significant numbers of bits, ad-hoc
methods fail miserably.

> 	Place an *audio* CD in the CD-ROM drive. Most CD-ROM drives know
> about audio discs now, and I believe they can be made to read the binary
> waveform data even if they don't understand the Red Book audio
> format.

If you are going to use this for cryptography, is an ancient cipher
known as a book cipher, updated to use CD-ROMs. This is NOT a secure
way to encrypt things. Although its probably better than most silly
schemes people come up with, it isn't as good as real cryptosystems,
and they are available, so why use such a hack?

> 	What do you all think?

I think its good that you are evincing enthusiasm, but I really think
you ought to learn more cryptography. Remember, most obvious ideas
have already been thought of -- others are often as bright as you are,
and have come before you. Ask yourself why someone else hasn't done it
before proposing things.

Perry

> How do you pick the random section in the first place? Oh, I see, we
> use a random number generator!

Every PRNG needs to be seeded somehow.  I was thinking he meant to
start the process with a secret key.  The main problem I see (assuming
you hash the blocks down to get decent random data) is that CD-ROMs
aren't all that big.

(The vast majority of CD-ROM drives, by the way, cannot make a bit-for-bit
 copy of audio CD's.  The record industry was unhappy with this idea.)

   Eli   ebrandt@hmc.edu

Data on CD-ROM will in general be decidedly non-random, unless the
CD-ROM was purposely generated as a collection of random bits.  ASCII
text files and executables have all sorts of structure.  Even music
CD's are pretty useless as random bit sources.

--
| GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5@tivoli.com>       |
| TAKE TWA TO CAIRO.          ||| Tivoli Systems, Austin, TX:        |
|     (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |

This strikes me as another variant on the venerable 'book' cypher.    
To quote Kahn (is that even close?  The guy who wrote _The Code  
Breakers_.) 'What you gain in key size, you loose in key coherency.' 
In general book ciphers are not very strong.  (At least thats what I    
think the big boys said...) 
   
  But, speaking of random numbers.  In Crypto '92 (or '93?) there is    
this great protocol for two players (Andy and Beth say) to listen to a  
poorly heard (radio) source (a low power satalite, or perhaps Radio    
Free Bosnia) and extract a shared secret key -- even when an evil  
opponent (Eve say) is listening with much better equipment.  This is 
really a great result!  It is at least as exciting as DH key exchange  
(to me).  It's strength is based on probability and information theory    
and not on 'unproven' complexity theory assumtions (such as 'discrete   
logrithms are hard to compute').  But -- how do we make it work on the
net?

j'
--
		   O I am Jay Prime Positive jpp@markv.com
1250 bit fingerprint B06229 = B8 95 E0 AF 9A A2 CD A5  89 C9 F0 FE B4 3A 2C 3F
 524 bit fingerprint 2A915D = 8A 7C B9 F2 D5 46 4D ED  66 23 F1 71 DE FF 51 48
Public keys via `finger jpp@markv.com', or via email to pgp-public-keys@io.com
Your feedback is welcome directly or via my symbol JPP on hex@sea.east.sun.com

Resist the Clipper Chip, write "I oppose Clipper" to Clipper.petition@cpsr.org