OMGWTFRNG (OWR)
Overview
Modern encryption algorithms are only as good as the random number generator(RNG) that they use. If using the normal rand() function of C, you have to seed the algorithm(Usually with the current time). To get back out all the random numbers an attacker only needs to find the seed value. I made a program(Random Obfuscation Tool) a long time ago that abuses that fact. This program/library is basically every way I could think of to get random numbers mashed together, to hopefully get a pretty good source of non-guessable randomness without needing external hardware. /dev/random is a good source, but only if you can't predict the entropy pool. Using /dev/random right when you've booted your computer and done set things(IE typed in your name and password) would be reversable, although still unlikely.
Description
This is actually a slew of C programs, the most usefull one probably being the xorFiles program, which takes any files and XORs them together, and tries to be fairly complete:
- Can go till the end of the smallest file or a set number of bytes
- If a file is shorter than the requested bytes it will loop over and reuse it(IE an XOR password)
- Can give a truly random set of typable characters. Discards non-printable characters so that something like mod doesn't skew the distribution.
The script uses all the programs to XOR the following data together:
- Clock drift in the system
- Atmospheric data from random.org
- /dev/random (Which is entropy from user interaction run through SHA1)
- An AES based RNG that Chris made
Source
- owr.tar.gz -- Tarball of all files, including a makefile and Chris's AES RNG(Requires the gcrypt library, which most people should already have installed)
- xorFiles.c -- Program to xor any number of files together
- parseNumbers.c -- Very small C program just for parsing random.org's values
- clockDrift.c -- Produce random data based on the CPU's clock. I have tested this by spawning over 200 processes to run simultaneosly, and fully utilizing the CPU, to make sure that the context switching wouldn't cause issues(IE the clock drift program doesn't get it's quanta till the set number of ticks has passed). It still produced completely random data, but just to be safe you shouldn't run it if you fork bomb yourself ;).
- randomScript -- Produces how many ever random bytes of data you want utilizing all of the methods listed above
- compareScript -- Generate raw data for each method.
Comparison
Each method was run 20 times generating 1kB and averaged, using the incredibly helpful ent program. The lower values returned the better the random data. The graph below sums up the results(Click for a bigger version):
Note that chi squared was divided by 10, and the serial correlation and Monte Carlo were multiplied by 10, just so they could all show up in the same graph.
Conclusion
XORing everything together works really well, but it is slightly slow since it is grabbing so much data and the entropy pool must be sufficiently high to keep /dev/random fed. Personally I'm very pleased with the clock drift results(Although it did poorly on the serial correlation test, meaning there is some correlation between successive bytes) and will probably use it when I need large quantities of random data in situations where /dev/random would be too slow.
Comments(0) 
2009-01-18 20:37:55
Add your comment:
Hardware
Software
- TAIM (Alpha Version): GHCI integration with vim
- CheaTorrent -- An evil BitTorrent client
- Self Modifying 2D Turing Automata
- Competing Conway Life Automata
- X11 Timelapse Desktop Video
- Colored Wolfram Automata With Sound Input
- Pseudo Video Feedback in Processing
- Haskell Cipher Saber
- Illegal FIlenames -- Windows and *nix
- Simple Perl SDL Music Keyboard (Updated)
- Image to Spectrogram
- Pastebin Hell
- OMGWTFRNG (OWR)
- OTP Enhancement : Failure Report
- Java Network File Transfer Tool
- AES Encrypted Filesystem Speeds
- Dual Message Encryption
- PHP Website
- Mp3 Splitting Script
- Random Obfuscation Tool
- Filesystem Speed Comparisons
- Java Based Web Server GUI