Show Posts
Pages: 1 [2] 3 4 ... 48
16  Development / Other Software Development / Re: Update to the Entropy Library on: March 23, 2014, 11:27:22 am
Certainly possible, but with over 5,000 downloads of the library I would expect the title should attract its user base.  Of course, like most marketing concepts I could be wrong :-)
17  Development / Other Software Development / Re: Update to the Entropy Library on: March 23, 2014, 10:02:21 am
Is no one interested in testing this on ARM platforms?  I do not have any such platforms I can test this library on and would appreciate any help the community can provide.
18  Development / Other Software Development / Re: avr-libc random performance? on: March 23, 2014, 08:25:59 am
Good intro to the subject
19  Development / Other Software Development / Re: avr-libc random performance? on: March 21, 2014, 02:26:44 pm
For anything important you should NEVER use a library random number generator.  There are plenty of examples of good PRNG's that cover the gamut of needed system resources, including some with a very light footprint.  The built in library PRNG's are only good for student level exercises, and for learning the value of not making assumptions!
20  Development / Other Software Development / Re: Update to the Entropy Library on: March 21, 2014, 07:44:01 am
I am older than you might think; however, I have found it best when dealing with folks online to take their posts at face value! :-)
21  Development / Other Software Development / Re: Update to the Entropy Library on: March 20, 2014, 05:19:50 pm
I don't know if the question is serious or not, but no it is not related to that site.

The library makes use of the jitter associated with the cpu's timers to generate true random numbers.
22  Development / Other Software Development / Update to the Entropy Library on: March 20, 2014, 03:42:36 pm
Paul Stoffregen has provided an update to the Entropy library that allows it to work on the ARM chip he uses for his Teensy 3.1 boards and is also producing test data for a couple of scenarios, the first of which has been posted to the wiki page.  It is possible that this will also work on other ARM based arduinos but that will require folks to try the library and test it.

If you choose to test this on an ARM board (or another AVR) just load this sketch to the board and capture the output to a text file for at least 12-24 hours.  Then send me the output file along with information on the board, the cpu type, its date code, etc...  You can see examples of the information I need for each test (less the analysis which I will perform) on the wiki page for the library:http://code.google.com/p/avr-hardware-random-number-generation/wiki/WikiAVRentropy

Code:
#include <Entropy.h>

void setup()
{
  Serial.begin(115200);
  Entropy.Initialize();
}

void loop()
{
  Serial.println(Entropy.random());
}

Google Code has implemented a change that prevents me from placing a zip file containing the library on the sites Download page; however, I have placed such a zip file on a Google Drive and it is linked from the wiki page.  You can also obtain the library by using the more traditional google code interface (git, svn, etc...)...
23  Using Arduino / Programming Questions / Re: Random numbers to char array?? on: February 05, 2014, 02:37:57 pm
You can generate a random number in the range 0 .. 9 by calling random(10). Note that the returned values will not be truly random unless you first call randomSeed() with a random value such as the result of analogRead() on an unconnected pin.

May not be important to the OP's need, but what you describe would not be truly random.  Indeed it would results in quite predictable results.
24  Using Arduino / Programming Questions / Re: AnalogRead for a Random Seed. on: January 20, 2014, 11:00:19 am
The links provided by CB provide plenty of evidence that AnalogRead is always a bad source for entropy.

Here is a single link to a post where I actually provided measurement evidence of the problem (something that should be done for any source of 'entropy' that is being considered for use.

http://forum.arduino.cc/index.php?topic=111868.msg840693#msg840693

OP, for your stated interest (a box of entropy to feed a windows machine) you can find code, circuits, and test data at http://code.google.com/p/avr-hardware-random-number-generation/

If you can get by with a relatively slow generation rate, about 8 bytes per second, the Entropy library at the above link can work with nothing more than a plain jane arduino.

For faster generation rates there are two other options that I have tested on that link.  Radioactive decay, and avalance noise from a reverse biased transistor.  The radioactive decay was a problem for long term use since two geiger counters from two different manufacturers failed in much the same manner in fairly short order.  However, if you are willing to risk replacing the geiger counters fairly regularly, then it works.  However, without a fairly high radiation source the generation rate will still be fairly low (couple of megabytes per day).

I have found avalanche noise to be the best source that will produce the best entropy rate, about 40Mb per day.

No matter what source you decide to use, it should be tested before it is relied on.  Even those designs I present in the above link which worked for me.  Individual environments and assembly can introduce significant biases, that require testing to ensure the source is valid.  The above link also provides some explanation of basic testing as well as source of software for more thorough testing if your needs demand it.

Oh, and having a truly random seed is only part of the battle.  The quality of the pseudo random number generator used is also vitally important.  The ones built into ALL operating systems are quite poor from a crypto-graphic sense and even with a 'true and perfect' random seed will still be easily broken.  The book mentioned above is a good start to learning how to implement/select a good pseudo random number generator.
25  Using Arduino / General Electronics / Re: Additional Information on Avalanche Noise for entropy gathering on: December 24, 2013, 10:02:03 am

Have you tried / considered using something like this for whitening...

• Save reading A
• Save reading B
• If A == B start over
• If A < B output zero otherwise output one

I believe that's essentially how atomic decay based generators whiten (using time between events instead of analog value).  It should eliminate the need to calculate / refresh a median and should naturally compensate for changes in the hardware.


Yes, I incorporate the Von Neumann whitening as one of the whitening techniques I use in the source for this project...  Of possible interest, is that by itself, it didn't work to provide a uniform distribution to the entropy produced by my radioactive decay (RD) test bed either.   I suspect that the bias issues I noted were caused by the physical measurement devices used (ie Arduino Mega) since the radioactive decay is considered the 'ideal' random entropy source.  Even Mr. Walker notes, that his set-up requires whitening (the Von Neumann you mention), which does seem to confirm that simply 'measuring' the time between decays introduces some bias.

 I haven't seen any reports of the issues that arose with my RD tests, but I have abandoned further testing on that area since I am tired of replacing expensive geiger counters.  Using the same Arduino Mega computation bed, I started out with an Aware RM60 (same as John Walker's Hot bits) and sealed the counter and a radioactive source in a lead box.  Over a period of time, the counter showed progressively higher generation rates that had me wondering if my source was getting more 'radioactive'...  Though not normally possible, if some aspect of the test setup was generating neutrons it was theorectically possible,,,

I purchased a second counter, to get an independant estimate of the radioactivity of my source.  As should have been the case, it hadn't changed.  Indeed the RM60 showed the same extraordinarily high count levels, even when it was only being subjected to normal background radiation.  My conclusion was that some aspect of the counter's circuitry failed.  So I replaced the RM60 with the Images SI counter I had used to verify the radioactivity level.  That lasted about six months (about 1/4 the time it took for the RM60 to fail) until it too exhibited the exact same problem.  I sent Mr. Walker an email to see if he had ever encountered a similar problem; however, I never received a response.  Given the several hundred dollar cost for these 'cheap' geiger counters I didn't want to ruin a third.  I suspect some aspect of these counters circuitry fails if left running 24x7...

Curiously, the RM60 failed completely shortly after it was removed from the test environment.  The Images SI counter still works, technically; however, it reports a count level that one might expect inside a nuclear core when it is only subjected to normal background radiation.  I haven't gotten around to trying  to diagnose the problem.
26  Using Arduino / General Electronics / Re: Additional Information on Avalanche Noise for entropy gathering on: December 24, 2013, 09:47:02 am
Is there code to both collect entropy from such a circuit and also perform basic sanity
checking to detect circuit malfunction (before releasing the supposed entropy to the
caller)?

I've been playing with the new Due and have yet to try out its built in RNG.

The ent utility was created to perform the exact procedure you are describing.  
John Walker uses it to monitor samples from his radioactive decay based TRNG as a QC measure.  He discards his 'entropy' as it is read.  Using the more sophisticated tests, such as dieharder or TestU01 would be problematic, since they require hundreds of megabytes of data to perform a complete test and even then, true RNG's will fail the occasional parts of those tests, just not in a predictable way.  That is why multiple test runs are nescessary to ensure that the TRNG is producing valid output.  The Chi square test is the best way to identify a problem quickly with a TRNG.  If two consecutive test results are outside the range 0.01 > p < 0.99 then a given TRNG has a problem.  Of couse, the 'test' passage doesn't mean that the TRNG doesn't have other subtler problems, which is why the more strident tests are needed.

If you want to implement the chi-square test in the Due, the source from the ent utility would be a good place to start.  It implements the chi-square calculation AND the cummulative probaility density function needed to convert the raw ChiSq value to a probability.
27  Using Arduino / General Electronics / Re: Additional Information on Avalanche Noise for entropy gathering on: December 23, 2013, 10:01:13 am
That is a much more complicated question than you might be aware of.  First the diehard series of tests have a number of known flaws, which is why they have been superceded by other more refined tests such as dieharder and TestU01 among others.  All of these testing suites are really designed to test psuedo-random number generators so they have an issue with true random generators which by definition will occasionally fail some of their tests, but if tested again with a new batch of data will not fail in the same area.  PRNG's will tend to fail in very predictable ways, where TRNG will only fail the tests occasionally and with no predictable pattern.

A simple illustration of this issue can be found by looking at the results for the chi-squared probabilities provided...  The general rule is that probabilities of < 2.5% or > 97.5% are considered fails...  So if you simply use those measures you find a fair number of fails among the 1200+ samples produced.  However, such occasional 'failures' are in fact very consistent with the behavior expected from a truly random source.  If the source were flawed one would expect failures from much further along the 'tails' of the distribution and that those failures would be more frequent (and predictable).

So to answer you question, I am continuing to run dieharder and TestU01 tests on the data as new data samples become available (dieharder required a minimum of 400 MB of random data) and while the occasional test is found to have been 'failed', no pattern or consistency is found when the same suite of tests is performed on the next round of data samples.

So far it appears that the real area of concern with this source of entropy is not the entropy capability itself, but rather its potential susceptibility to outside influence if the circuit is not properly implemented, tested, and kept shielded.  In short the physical security of the device is paramount to maintain the integrity of the entropy source.
28  Using Arduino / General Electronics / Additional Information on Avalanche Noise for entropy gathering on: December 21, 2013, 04:09:21 pm
I have updated the google code page with additional information on my research into the long term performance of using valanche noise to generate entropy (random numbers).  In addition to adding more detailed information on the first 811 10,000,000 byte samples that were collected as of last year, I have added another 400 samples from the same circuit.  This was after leaving the circuit powered off for about eight months.

The results are intriguing, as you can see from this graph of the median calculated prior to the generation of each 10,000,000 byte sample file.



The medians start out much higher than they were in the first set of samples, but after about three weeks they settled into much the same pattern that had existed in the first set of samples.

One modification, I made in Mr. Seward's idea of performing a 'calibration' by calculating a median of the first few bytes.  It is these medians that are displayed in the above graph.  The preliminary analysis of the entropy's performance, particularly in relation to the median calculated for that particular set indicate that no relationship exists.  This would be partially explained by the additional whitening operations (von Newman, etc...) performed by the software.  I suspect that two factors are in play.  First, one needs only the approximate middle value to determine 1's and 0's for the whitening algorithms to produce reliable uniform randomness.  Secondly, I believe that regular median calibration will help maintain the generation rate of the circuit.  Since, the von Newman portion of the whitening algorithm serves to remove any consecutive bits with the same value.

If you want to look at the more detailed results from these initial studies, they are available from http://code.google.com/p/avr-hardware-random-number-generation/wiki/AvalancheNoise  The following is available for each of the 1200+ 10,000,000 byte entropy files gathered to date.

Code:

Value Char Occurrences Fraction
   0         40002017  0.5000252125
   1         39997983  0.4999747875
Total:       80000000  1.0000000000
 
 
Value Char Occurrences     Fraction Expectation    Deviation
   0           39,303  0.393030000%   39,062.50     240.5000
   1           38,890  0.388900000%   39,062.50     172.5000
 ...
 254           39,026  0.390260000%   39,062.50      36.5000
 255           39,074  0.390740000%   39,062.50      11.5000
Total:     10,000,000  100.0000000%      Mean =     159.1172
 
Entropy = 7.999982 bits per byte.
 
Optimum compression would reduce the size
of this 10,000,000 byte file by 0.00%
 
Chi square distribution for 10,000,000 samples is 249.24, and randomly
would exceed this value 58.99% percent of the time.
 
Arithetic mean value of data bytes is 127.5027 (127.5 = random)
Serial correlation coefficient is 0.000010 (totally uncorrelated = 0.0).



Of note is that none of the produced files have failed the ent style entropy tests since the very first few, while I was still revising the whitening algorithm...  And preliminary tests using more rigourous testing procedures have yet to find any issues with the data produced.  A caution for those considering using this type of circuit in any critical area.  The electronics are very sensitive to construction issues, and outside noise sources.  The whitening helps filter out the latter, but a strong enough outside signal source could compromise the circuit.  Assembly in an EMI shielded case, and other precautions should be implemented with any critical application.
29  Community / Products and Services / Re: Arduino Cases, Machined aluminum and Walnut on: October 18, 2012, 09:22:47 am
I have made similar cases for some projects in the past (wooden).  Instead of using screws, you should consider using the very small rare earth magnets to hold the lid in place.  They work very well, and as long as they don't interfere with the sensors your using, they can offer a cleaner look to the case.
30  Development / Other Software Development / Re: Beta testers needed for a new library that generates true random numbers on: October 08, 2012, 03:09:39 pm
Yes, more results would be helpful.
Pages: 1 [2] 3 4 ... 48