<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 30, 2014 at 9:25 AM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">>> One question: how does it look to software? I'm not in a position to<br>
>> do any device driver writing, or mucking around with Linux kernels...<br>
>> I'm using MacOSX and writing from Java so I essentially want either a<br>
>> tty or a file device surfaced so I can read the thing directly from<br>
>> userland.<br>
</span>...<br>
<span class=""><br>
> It uses a common USB chip (FTDI FT240X), so the driver is already available<br>
> for Mac OS-X.<br>
<br>
<br>
</span>I think it is essential for these devices to pop up and be available<br>
without fuss. In essence this means that if it emulates other standard<br>
devices, then it wins.<span class=""><br></span></blockquote><div><br></div><div>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.<br></div><div> <br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> You just run a user-space C program I wrote to access it,<br>
> since the open-source libftdi has a C API.<br>
<br>
</span>OK, will read. Are you saying I need to get that installed? If it has<br>
to be a user-installed device driver, I think you'll find a bit of a<br>
drag in the market place. But let's see how robust this is first.<span class=""><br></span></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> From Java, I would just launch<br>
> it with stdio communication, which I've found to be reliable.<br>
<br>
</span>Does it surface a device file in /dev? If I can find the file, I can<br>
handle the rest. Or are you saying that the user-space C program has to<br>
be run to get access in a program because the driver doesn't have ioctls<br>
and so forth?<span class=""><br></span></blockquote><div><br></div><div>Yes, it creates on of those serial port thingies. The libftdi deals with the device communication for me.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> You control<br>
> whether I turn the Keccak whitener on with command a line parameter. It<br>
> just spits binary data at you over stdout and blocks until you read it.<br>
> stderr is used for debug and error reporting.<br>
<br>
<br>
</span>OK. Have you had a go at measuring the results through 'ent' so we can<br>
compare to Paul's results? I don't think this is a big deal but the<br>
market is oriented to numbers [1], so they will expect to be able to<br>
compare them and wax pontifical. E.g., RSA 1024 is clearly twice as<br>
strong as EC 512...<span class=""><br></span></blockquote><div><br></div><div>Since you asked, I just did :-) Here's the end of my debug output:<br></div><div><br>$ sudo ./infnoise-v1 --raw --debug > foo<br>...<br>Generated 14680064 bits. OK to use data. Estimated entropy per bit: 0.866710, estimated K: 1.823500<br>num1s:49.888504%, even misfires:0.159748%, odd misfires:0.127300%<br>Generated 15728640 bits. OK to use data. Estimated entropy per bit: 0.866856, estimated K: 1.823684<br>num1s:49.901504%, even misfires:0.145973%, odd misfires:0.160365%<br>Generated 16777216 bits. OK to use data. Estimated entropy per bit: 0.867010, estimated K: 1.823879<br>num1s:49.963040%, even misfires:0.146815%, odd misfires:0.145067%<br><br></div><div>Here's ent's results on the raw data stream this run produced:<br><br>$ ent foo<br>Entropy = 7.318058 bits per byte.<br><br>Optimum compression would reduce the size<br>of this 2072576 byte file by 8 percent.<br><br>Chi square distribution for 2072576 samples is 1510131.51, and randomly<br>would exceed this value 0.01 percent of the times.<br><br>Arithmetic mean value of data bytes is 127.5088 (127.5 = random).<br>Monte Carlo value for Pi is 3.427100794 (error 9.09 percent).<br>Serial correlation coefficient is -0.005035 (totally uncorrelated = 0.0).<br><br><br></div><div>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.<br></div><div><br></div><div>Maybe I should offer my entropy estimator as an alternative to ent? I could compress this file by 13.3%.<br></div><br></div><div class="gmail_quote">My entropy estimator is based on the model that:<br><br></div><div class="gmail_quote">- The device is not rapidly changing the sort of numbers it puts out, so I can use history as a guide.<br></div><div class="gmail_quote">- bits further away are less correlated.<br><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div>Bill<br></div></div>