6
$\begingroup$

I have a physical unit, e.g. a resistor. I bias it with current and measure the voltage. Let us assume that the fluctuations ($\Delta V=V-<V>$) of this voltage signal are random. Now, $\Delta V$ contains floating numbers with some certain significant digits, say [1.243, 3.567, -3.987, ..., etc]. To test these random numbers (using something like DieHard test), I need to convert these values into binary, 0 or 1.

How do I do that? One way to do it is to set a limit, say 0, such that positive values are mapped to zeros and negative values are mapped to ones (or vice versa). Is there any better way to do it?

$\endgroup$
  • 1
    $\begingroup$ How many bits do you want to get from each fluctuation? If you're OK with one and the sign is fully random each time, just use the sign. $\endgroup$ – SEJPM Nov 8 '15 at 22:41
  • $\begingroup$ Well, right, but what I am asking is whether there is any standard practice used in this case? Also, if I want more than one bit, then again I can sit a limit for each digit separately...Apparently there should be a better (or more standard) way to do it? $\endgroup$ – student1 Nov 9 '15 at 0:00
  • 2
    $\begingroup$ Define better; or in other words, your objective. The objective of crafting a RNG using what you have that pass a DieHard test is ridiculously easy to reach (the only mildly difficult things are getting the DieHard test to work correctly, and interpreting its output), and largely pointless. Studying the source to determine its entropy rate, and from that the odds that this RNG gives identical output on two different uses, is a different matter. For the later, you'd like to know how the numbers you get are generated; if they are "floating numbers" they most likely are not a raw ADC output. $\endgroup$ – fgrieu Nov 9 '15 at 4:28
  • 2
    $\begingroup$ Is there a better way to do it? Yes, don't do it! Designing a cryptographic random generator is an art. It is presumably the most difficult to build hardware part on any cryptographic hardware device. $\endgroup$ – user27950 Nov 9 '15 at 4:41
  • $\begingroup$ @fgrieu My objective is to use this physical source as a RNG. But why is it 'pointless'? The numbers are the direct output of the ADC (using some instrumentation interface -- LabView, for instance) $\endgroup$ – student1 Nov 9 '15 at 4:49
3
$\begingroup$

What you want to do depends on your objective.

If you only want to make a good RNG from the values you have, so that it passes a Diehard test (passing the test being the objective), that's fine and easy. You do not need to know, or care, about how the values are obtained; essentially, you can take whatever form the "floating numbers" reach you (be it characters coding numbers in decimal separated by newline character, words in whatever IEEE 754 format..) and feed that to a CSPRNG. Here is one of the simplest possible implementation: you decide a number $n$ of values to process (or a duration during which values will be processed), and hash whatever form the "floating numbers" representing these values reach you using SHA-256, giving a 256-bit $H$. You then produce random bits using HMAC-SHA-256, with key $H$, and input some counter initialized to zero and large enough to never repeat. This output will pass DieHard or any pre-existing RNG test (that works and is correctly interpreted). That's including if $n=0$ (illustrating that passing such test is not a good argument that a RNG is a good TRNG).

A very different objective is estimating how likely it is that a RNG made according to the above sound principle (feeding a CSPRNG with your source) gives the same output for $m$ uses (especially: on power-up of some device under some well-defined and attacker-controlled conditions), and how large $n$ should be to make this practically impossible. To do this accurately based on an analysis of a stream of the "floating numbers" (rather than on actual data gathered at numerous power-up), a good model of the physical setup and data processing chain leading to the "floating numbers" would be required.

But what you get with LabView from a modern digital scope (or worse, voltmeter) has gone through much undocumented preprocessing, so you can't do this. It remains a reasonable objective to give a lower bound on the actual entropy gathered. Update 2: A RNG test such as DieHard is not intended for this, but here is something derived that should do: replace each pair of "floating number" by bit 1 if the first number is more than the other, or 0 otherwise. If the resulting sequence pass the DieHard test, then it is likely that each "floating number" has at least $1/2$ bit of entropy (thus feeding all the bits in $n=512$ consecutive representations of "floating number" will seed any sound CSPRNG with at least 256 bit of entropy). If not (that'll depend on the source), try again replacing each set of $k$ bits by the XOR of these bits, increasing $k$ until the test pass; then it is likely that each "floating number" has at least $1/2k$ bit of entropy, so that $n=512k$ will do.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Aha. Sounds like what Intel uses in their IvyBridge processor's RNG (RdRand): they have a Source of Entropy that feeds a PRNG... $\endgroup$ – student1 Nov 9 '15 at 5:30
  • 1
    $\begingroup$ Your simple RNG suggestion lacks forward security. $\endgroup$ – otus Nov 9 '15 at 6:36
  • $\begingroup$ @otus: Yes. I took one of the simplest construction that will pass any RNG test based on its output, since the question as I read it focuses on passing such test. $\endgroup$ – fgrieu Nov 9 '15 at 7:27
1
$\begingroup$

Voltage signal into binary is fairly difficult for this scenario. You'll actually find the the crypto aspects of this are the easy bit. LabView will record the signal level automatically and that's the digital conversion done for you. Just shove your numbers up some decent hash and there you go. The problem is the voltage readings themselves.

Despite various protestations that you'll read to the contrary, there is no standard methodology for this process called randomness extraction. There can't be as the there is no standard hardware layout. It's customary to roll your own extractor mechanism for your hardware. Some use hash functions like SHA-1, some use various XOR and bit shifting techniques. Others use binary counters, timers or level comparators. Some whiten the output; some don't need to.

You're suggesting level comparison. This is where this question is off topic for this forum and better addressed to the guys in electronics. A + /- mapping to boolean values theoretically works, but the hardware will be a pig to get right. You give signal levels of 8 V P-P from a microvolt Nyquist source. That's a gain in the order of 130 dBV. LabView isn't designed for this application without other bits of signal processing hardware. Amp slew rate, mains induced noise, capacitance induced oscillations and thermal drift of the reference voltage will all bite you. The effect will be that a simple Von Neumann extractor won't work due to auto correlation in the signal output. This bias may fail Diehard over it's 10MB sample. Again, questions for the sparky's.

If you're not bothered about true random numbers, seeding some sort of PRNG will work okay. Directly seeding Blum Blum Shub with an Java BigInteger constructed from the signal level bytes would be a good solution. It would negate all biases and correlations. Whether you choose a secure generator is your choice depending on your final purpose for the random numbers. If you want true random numbers generated directly from the signal on a bit by bit basis, you really need to look at the schematic design first, then follow up with software.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.