[onerng talk] Putting Inf Noise on Tindie in non-competitive way?

[Bill Cox]

On Thu, Oct 30, 2014 at 9:25 AM, ianG <iang at iang.org> wrote:

> >> One question:  how does it look to software?  I'm not in a position to
> >> do any device driver writing, or mucking around with Linux kernels...
> >> I'm using MacOSX and writing from Java so I essentially want either a
> >> tty or a file device surfaced so I can read the thing directly from
> >> userland.
> ...
>
> > It uses a common USB chip (FTDI FT240X), so the driver is already
> available
> > for Mac OS-X.
>
>
> I think it is essential for these devices to pop up and be available
> without fuss.  In essence this means that if it emulates other standard
> devices, then it wins.
>

That is part of the idea behind using the FT240X.  There are both
commercial and open-source drivers for it.  In Windows, it is recognised
and the USB driver is auto-installed.  It creates a virtual COM port that
is simple to deal with.

However, because I control the INM through bit-bang mode, I have to drive
the INM clocks from the application side, or else write a custom driver.
This is the disadvantage of not having the microcontroller on the USB key.
The health monitoring and whitening are also done in the application side.
I can make this a library for C linking, and I could also do a native Java
port.  I find Java is the least forgiving language for interfacing to
native C, so it would be better just to do it all in Java, I think.

> You just run a user-space C program I wrote to access it,
> > since the open-source libftdi has a C API.
>
> OK, will read.  Are you saying I need to get that installed?  If it has
> to be a user-installed device driver, I think you'll find a bit of a
> drag in the market place.  But let's see how robust this is first.
>

It's auto-installed in Windows.  Ubuntu required an apt-get install, and I
don't know yet about Mac, though I hear there are existing Mac OS X drivers.


> > From Java, I would just launch
> > it with stdio communication, which I've found to be reliable.
>
> Does it surface a device file in /dev?  If I can find the file, I can
> handle the rest.  Or are you saying that the user-space C program has to
> be run to get access in a program because the driver doesn't have ioctls
> and so forth?
>

Yes, it creates on of those serial port thingies.  The libftdi deals with
the device communication for me.


> > You control
> > whether I turn the Keccak whitener on with command a line parameter.  It
> > just spits binary data at you over stdout and blocks until you read it.
> > stderr is used for debug and error reporting.
>
>
> OK.  Have you had a go at measuring the results through 'ent' so we can
> compare to Paul's results?  I don't think this is a big deal but the
> market is oriented to numbers [1], so they will expect to be able to
> compare them and wax pontifical.  E.g., RSA 1024 is clearly twice as
> strong as EC 512...
>

Since you asked, I just did :-)  Here's the end of my debug output:

$ sudo ./infnoise-v1 --raw --debug > foo
...
Generated 14680064 bits.  OK to use data.  Estimated entropy per bit:
0.866710, estimated K: 1.823500
num1s:49.888504%, even misfires:0.159748%, odd misfires:0.127300%
Generated 15728640 bits.  OK to use data.  Estimated entropy per bit:
0.866856, estimated K: 1.823684
num1s:49.901504%, even misfires:0.145973%, odd misfires:0.160365%
Generated 16777216 bits.  OK to use data.  Estimated entropy per bit:
0.867010, estimated K: 1.823879
num1s:49.963040%, even misfires:0.146815%, odd misfires:0.145067%

Here's ent's results on the raw data stream this run produced:

$ ent foo
Entropy = 7.318058 bits per byte.

Optimum compression would reduce the size
of this 2072576 byte file by 8 percent.

Chi square distribution for 2072576 samples is 1510131.51, and randomly
would exceed this value 0.01 percent of the times.

Arithmetic mean value of data bytes is 127.5088 (127.5 = random).
Monte Carlo value for Pi is 3.427100794 (error 9.09 percent).
Serial correlation coefficient is -0.005035 (totally uncorrelated = 0.0).


It looks like I do a much better job at estimating the entropy than ent.
The actual non-randomness is 60% higher than ent predicted.  Ent said 0.915
bits of entropy per bit, while I measured 0.867.  My entropy estimator is
just a tiny fraction of a percent higher than reality, while ent is off
by4.8% .  The design target for entropy per bit was log2(1.82) =
log(1.82)/log(2) = 0.864.  This is set by two resistors.  All three boards
are within 0.5% agreement with the model's prediction.  I have to say, I
find that really cool.

Maybe I should offer my entropy estimator as an alternative to ent?  I
could compress this file by 13.3%.

My entropy estimator is based on the model that:

- The device is not rapidly changing the sort of numbers it puts out, so I
can use history as a guide.
- bits further away are less correlated.

I have runs where I compute a significant enough sample to predict the odds
of the next bit being a 1 given the previous 24 bits.  However, I use only
14 bits of history in the health monitor because I see no significant
improvement in entropy estimate when I go higher, it uses less memory, and
can track a dynamically changing device (due to temperature or whatever)
more quickly.

Regardless of how much entropy I measure in a snippet, I always claim no
higher than 2% lower than the design target.  The health monitor stops
output if measured entropy is off by more than 2% vs the model, so the
average entropy per snippet (512 bits) should always be at least this
high.  However, if an attacker can inject a signal, he can cause the INM
output to create a snippet that appears more random than it is, and if I
claimed the snippet was significantly more random than average, an attacker
might be able to make use of that.  If an attacker makes a lot of snippets
appear more random than they are, the average entropy will rise 2%, and the
health monitor will turn off the output.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/discuss/attachments/20141030/d40c05ff/attachment.html>