handling weak keys using random selection and CSPRNGs

Greg Rose ggr at qualcomm.com
Sat Oct 14 19:15:44 EDT 2006


At 5:22  +0200 2006/10/14, Marcos el Ruptor wrote:
>>The only things that it usually passes as good are for-purpose random
>>number generators' or ciphers' outputs. Everything else (including a
>>terabyte of RC4 output, executables, zip archives, jpegs, mpegs,
>>mp3s, ...) that I've pointed it at, fails one or more of the tests.
>
>Have you tried removing the headers and trailing data?

Not specifically, but see below.

>
>>True random-looking-ness is hard to find... :-)
>
>Since when? There are plenty of easy ways to generate it. Many 
>compressed files will also pass your randomness tests if you test 
>only the compressed data itself, not the whole files.

I don't think so. If you look at the data I quoted in the email you 
quoted from, the difference in frequency between the most frequent 
byte and least frequent byte was over 500 occurrences. I doubt that 
the jpeg header alone could account for that, although I'll give you 
that since the byte value in question was zero, it may have something 
to do with it.

The jpeg header is more complicated than I want to take the time to 
understand at the moment. So here; I took the smallest meaningful 
jpeg I had lying around (taken from someone's low-res camera in 
2002), and I dropped about the first half of the file, keeping only 
the last 34k. Note that the very same troublesome statistics show up.










































I attach the picture in case anyone wants to duplicate the 
statistics. I'm the ugly one on the right. I don't even know who most 
of the other people are.

Now, you said "compressed files" and you might not have meant 
pictures, but note that L-Z style compressed files don't really have 
much in the way of headers. If the headers were a problem, you'd 
expect longer files to bury any deviation in the noise, but it 
doesn't. The longer the files I test the more certainly non-random 
they are.

I stand by my statements.

Greg.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StdsDinner2002.jpg
Type: application/octet-stream
Size: 69120 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20061014/0903609c/attachment.obj>


More information about the cryptography mailing list