Re: Trivial OTP generation method? (makernd.c)
On Thursday, March 6, 2003, at 03:16 PM, Peter Fairbrother wrote:
Tim May wrote:
On Thursday, March 6, 2003, at 12:05 PM, Peter Fairbrother wrote:
Thomas Shaddack wrote:
FIPS-140 is your friend. They did the math.
Cheers - Bill
fips140.c is a cool toy, thanks :) However, a bit unusable for my
purposes; the tests I run on data from /dev/dsp always fail. (I am
using
the tuner card, tuned to between the channels; visual test (cat
/dev/dsp)
looks like a noise.)
About 1% of this noise is cosmic-ray background, caused by cosmic
rays
hitting the atmosphere.
Unlikely in the extreme. Even galactic cosmic rays with TeV energies
are unimpressive when dissipating their (paltry) energy over several
hundred m^3, let alone over hundreds of km^3. The somewhat more common
GeV-energy particles are literally inconsequential.
GeV = 10^9 eV
TeV = 10^12 eV
One TeV in 10^-8 seconds is 10^12 {eV} x 10^8 {s^-1} / 6.12x10^18 {eV
J^-1}
or 16 Watts. 16 watts 50 km away will register on an untuned (ie with
maximun gain) TV receiver.
First, dumping all the energy in 10 nanoseconds is implausible.
Characteristic shower length, speed of light issues, etc. Get out your
calculator. (Hint: Many of the shower products even reach mountain
altitudes, sometimes even sea level.)
Second, even if somehow the energy of a TeV particle were to be
localized and dumped in the time you specify, an antenna 50 km away
would receive how much energy (power at source divided by roughly r
cubed, but lasting only the 10 ns you assume). No resonant detector
could see this, for obvious reasons of nonrepeatability, and no
ultrawideband pulse detector could see this.
Galactic cosmic rays go up to 4x10^21 eV. That's ~60 Joules, in say
10^-8
seconds, or = 6 GW =.
But so rare in any given region as to be notable events, which hardly
fits with their being part of the background noise in a sea level RF
detector.
Which is far more than any terrestrial TV transmitter I've ever heard
of.
I might be wrong, I haven't experimented myself and was just repeating
received wisdom. But not for that reason.
Get out your calculator. You're off by many, many orders of magnitude.
--Tim May
Stupidity is not a sin, the victim can't help being stupid. But
stupidity is the only universal crime; the sentence is death, there is
no appeal, and execution is carried out automatically and without
pity. --Robert A. Heinlein
Re: Trivial OTP generation method? (makernd.c) On 1e-16 BER and cosmic rays
At 05:50 PM 3/6/03 -0500, Tyler Durden wrote: On a slow day, Tim May wrote... Next you'll be claiming that chips can be influenced by cosmic and background radiation! When I used to characterize DWDM systems, we'd sometimes need to test down to a BER of 10(-14), with some vendors wanting 10(-16). (So we'd loop back a whole bunch of OC-48s and wait a few days for an error.) When operating under perfect conditions, once in a great while, with 16 or more OC-48s, we'd occasionally see an error. This we chalked up to cosmic rays, which I believed, but never really confirmed. The cosmic ray hypothesis has been criticized already. You might attribute a soft error to simple, local radioactive decay. [Hey, it worked for Tim] Background is ca. 10 uR/hr. Could be a few times higher if you have radon and don't ventilate e.g., at night. And stay out of the van Allen belts.. Errors might also be due to the random variables in your (noise, jitter, etc) models really being random, ie, eventually huge excursions. --- I'm pleased to announce we have outlawed Russia forever. We begin bombing immediately. -President Reagan (joking, unlike various sucessors)
Re: Trivial OTP generation method? (makernd.c)
On a slow day, Tim May wrote... Next you'll be claiming that chips can be influenced by cosmic and background radiation! When I used to characterize DWDM systems, we'd sometimes need to test down to a BER of 10(-14), with some vendors wanting 10(-16). (So we'd loop back a whole bunch of OC-48s and wait a few days for an error.) When operating under perfect conditions, once in a great while, with 16 or more OC-48s, we'd occasionally see an error. This we chalked up to cosmic rays, which I believed, but never really confirmed. -TD _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: Trivial OTP generation method? (makernd.c)
FIPS-140 is your friend. They did the math. Cheers - Bill fips140.c is a cool toy, thanks :) However, a bit unusable for my purposes; the tests I run on data from /dev/dsp always fail. (I am using the tuner card, tuned to between the channels; visual test (cat /dev/dsp) looks like a noise.) If I use the test on processed data, the test understandably doesn't fail even if the input before MD5ing is all-zeroes. The makernd output data pass the test in all cases, though.
Re: Trivial OTP generation method? (makernd.c)
What's wrong with the old trick of cranking the gain all the way up, plugging no microphone at all in, and getting thermal noise? Some modern soundcards have something like noise gate. From my PCI128 card I got about one bit of noise, and even that not consistently. Too high input impedance. Too easy to affect with external signals. Likely to pick up 50/60 Hz hum. Otherwise, it's good idea, but its application is likely to depend on the actual sound hardware used.
Re: Trivial OTP generation method? (makernd.c)
At 6:11 PM -0800 2/28/03, Thomas Shaddack wrote: Yes. The intention of the check in this version was to prevent operator blunders like feeding the program from a switched-off signal source. Better statistical check would be a good thing, though; however, my math-fu isn't good enough yet to come up with something simple. FIPS-140 is your friend. They did the math. Cheers - Bill - Bill Frantz | Due process for all| Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. [EMAIL PROTECTED] | American way. | Los Gatos, CA 95032, USA
Re: Trivial OTP generation method? (makernd.c)
* Using the output to seed MD5 for the next block exposes that part of the state of the RNG. Might be better to use half the MD5 output as seed for the next block, and the other half as output data. The RNG takes most of its input (except the initial seeding) from the external source of de-facto-impossible-to-predict-accurately data. However, it's a good comment; the program should allow to switch on this mode, trading added entropy for output stream rate (the program was originally intended as moderate-bandwidth, to produce a CD worth of random data in no more than few hours). * Your RNG takes input from an attackable source. The input - the TV tuner card audio device - was chosen on the basis of being available without me having to leave my chair when I got the idea; I am aware about this risk, though I don't expect an active attack of this kind ot be feasible against an offline OTP generator. However, I was playing with the idea of using a just-slightly-modified program to continually feed the entropy pool. Then the risk of active attack becomes more real. Also, vast majority of my computers don't have a tuner card in, so they will be dependent on an external noise source. Here a real noise generator has to come to play. Looking for something simple, powered from +5V. At this moment, I am pondering to design a small analog noise generator for the microphone input of a sound card (as most of my servers which could need this toy have an onboard soundcard). The mike input is designed for the electret microphone, which needs a power supply; the input is AC-coupled with a capacitor and connected to the power supply through a resistor. So there is a miliamp or two on few volts that I can use for the noise generator. Its usability as a power supply is likely to depend on the board/soundcard; I measured available voltages being 0.7V on a motherboard-integrated card, 2.5V on my POS laptop, and 4.8V on a PCI128 soundcard. With a simple noise-generator circuit (possibly a 1458 opamp fed with something like a Zener diode noise or anything similar suitable), it could be a very cheap and simple random noise generator (the whitening of the signal through a hash function is a must here, though, as the desired simplicity of the circuit will likely result in an uneven spectral distribution of the output, thus lower-than-optimal entropy). Even if the soundcard mike input won't offer high enough voltage, we can borrow +5V from keyboard, mouse, joystick, or USB port, for the cost of another connector and another piece of wire (which then turns an elegant neat clean sleek single-plug design into a wirey mess, but on the other hand allows us to put it all inside the server's case - then we can even take advantage of +12V available from the HDD power supply connector, and feed the signal into the CD-IN on the onboard sound card; using two independent noise generators and feeding their outputs to left and right channel could neatly double the input bandwidth). The point of this device isn't to have an absolutely-bulletproof system, but to provide good-enough-for-nearly-everyone el-cheapo HW RNG for under $10-15. be attackable - it would depend on how well I could manipulate the /dev/dsp output via my transmitter. You could eg. get the system to receive a continuous clean sine wave, or - more likely - feed it with high-amplitude impulses. Until I'll talk myself into putting together the hardware RNG from the previous paragraph. The present check only requires that some pair of bytes differ by 16 - something that might be relatively easy to cause with a transmitter. Yes. The intention of the check in this version was to prevent operator blunders like feeding the program from a switched-off signal source. Better statistical check would be a good thing, though; however, my math-fu isn't good enough yet to come up with something simple. Of course, reading 128 bytes buys you a lot of entropy even just from marginal noise, so you may still be okay. This was what I hoped for. :)
Re: Trivial OTP generation method? (makernd.c)
At 03:17 AM 2/27/03 +0100, Thomas Shaddack wrote: Here's what I do for random bits: http://www.etoan.com/random-number-generation/index.html Nice!!! :) I wasn't aware such electronics is so cheap! Note on RNG/hacking the PC-Geiger counter: If you want to change the RM-60's Time Base Unit, change byte 384 in the aw-rad.set file. [I reverse engineered this; Aware tries to sell software to do this.] This can be useful if you're using counts per unit time instead of inter-count intervals as your raw measurement and are using a hot source like Am241. The RM-60 is a great little toy for those of us not at CERN.
Re: Trivial OTP generation method? (makernd.c)
Several things: * Using the output to seed MD5 for the next block exposes that part of the state of the RNG. Might be better to use half the MD5 output as seed for the next block, and the other half as output data. * Your RNG takes input from an attackable source. I can significantly reduce the entropy of your system by placing a transmitter near your machine (even if I didn't know what frequency you were tuned to, I could try to just overload the receiver's front end, or burn it out entirely). If my transmitter and your receiver are very clean, the entropy could go quite low. With a better entropy check, that might just turn into a DoS attack, but even then it might be attackable - it would depend on how well I could manipulate the /dev/dsp output via my transmitter. The present check only requires that some pair of bytes differ by 16 - something that might be relatively easy to cause with a transmitter. Of course, reading 128 bytes buys you a lot of entropy even just from marginal noise, so you may still be okay. -J
Re: Trivial OTP generation method? (makernd.c)
After that, you actually want to feed the entropy you're getting
from the radio tuner *into* /dev/[u]random.
He may wish to pre-process the raw bits to remove any potential
bias they may have.
Here's what I do for random bits:
http://www.etoan.com/random-number-generation/index.html
Nice!!! :) I wasn't aware such electronics is so cheap!
Here is the final version of the OTP generator:
Hints and constructive criticism welcomed.
News: Elementary sanity check on input data is performed.
//-- cut here - makernd.c -- cut here
/*
## ###
##
## makernd - program for generation of random files suitable for one-time
## pads. Uses audio signal from soundcard input.
##
## Performs basic sanity check for sufficient entropy on the input.
## Reads 64 bytes from DSP, checks if there is at least one pair of
## adjanced bytes where the bytes are different by more than 16
## (arbitrarily chosen value). This should be replaced with some kind
## of statistical analysis. The check is also done on each block read
## from the input, discarding suspicious input data.
##
## Reads blocks of 128 bytes from RANDOMINPUT, hashes them with MD5,
## outputs 16-byte blocks to output file and RANDOMDEV (so as the side
## effect it feeds the entropy pool).
##
## Takes one mandatory parameter (number of random bytes to produce) and
## one optional parameter (output file name - uses stdout if not present).
##
## ###
*/
#include stdio.h
#include stdlib.h
#include openssl/md5.h
#define RANDOMDEV /dev/urandom
#define RANDOMINPUT /dev/dsprandom
char output[18];
FILE*fo,*frnd;
void outputbinary(char*s,long n)
{ while(n0)
{fprintf(fo,%c,s[0] 0xff);s++;n--;}
}
// FIXME: Replace with real statistical check
int isinsufficiententropy(char*data,int n)
{ int t;
for(t=0;tn-1;t++)if(abs((data[t+1]0xff)-(data[t]0xff))16)return 0;
return 1;
}
int checkinputentropy(FILE*f)
{ char data[64];
fread(data,64,1,f);
return isinsufficiententropy(data,64);
}
int output16bytes(FILE*f,long n)
{ char data[128];
MD5_CTX c;
MD5_Init(c);
MD5_Update(c,output,16);
for(;;){fread(data,128,1,f);
if(!isinsufficiententropy(data,128))break;
fprintf(stderr,Insufficient input entropy. Rereading block.\n);}
MD5_Update(c,data,128);
MD5_Final(output,c);
if(n16)n=16;if(n0)n=0;
outputbinary(output,n);
if(frnd)fwrite(output,16,1,frnd);
return 0;
}
int main(int argc,char*argv[])
{
FILE*f;
long n;
if(argc2)
{printf(makernd LENGTH [output.file]\n
Creates LENGTH bytes of random numbers derived from RANDOMINPUT,
which should be a symlink to eg. /dev/dsp0 fed with analog signal
from eg. a white noise generator.\n
Outputs to stdout if output.file is not specified.\n
Feeds the output also to RANDOMDEV.\n);
return 0;}
n=atol(argv[1]);
if(n=0)
{fprintf(stderr,Argument '%s' has to be greater than zero.\n,argv[1]);
return 111;}
f=fopen(RANDOMINPUT,r);
if(!f)
{perror(ERROR: Cannot open RANDOMINPUT);
fprintf(stderr,Check if the symlink or device exists.\n);
return 111;}
if(checkinputentropy(f))
{fprintf(stderr,ERROR: Input entropy seems to be insufficient.\n
No two adjanced bytes in RANDOMINPUT that are different by more
than 16.\n
Check the input signal volume.\n
Cowardly refusing to create any output.\n);
return 1;}
frnd=fopen(RANDOMDEV,rw);
if(frnd){fread(output,16,1,frnd);}
else{fprintf(stderr,Cannot open RANDOMDEV, cannot initialize output. Proceeding
anyway.\n);}
if(argc2){fo=fopen(argv[2],w);
if(!fo){perror(ERROR: Cannot open output file);return(111);}}
else fo=stdout;
while(n0){output16bytes(f,n);n-=16;}
fclose(f);fclose(frnd);
return 0;
}
