[Cryptech Tech] Improving the BP entropy source

[Bernd Paysan]

Am Mittwoch, 28. Mai 2014, 17:45:11 schrieb Joachim Strömbergson:
> Aloha!
> 
> Bernd, I have a few questions regarding the BP entropy source and how I
> use it. I would appreciate comments.
> 
> Right now I use it with the l-parameter i rosc.v as you had it
> initially, that is set to 8. That means that we have 8 bit add with
> carry as logic that drives the carry inverter. I I understood you
> correctly you recommended to reduce l to 2. This would reduce logic and
> should increase oscillator toggle frequency somewhat.

Yes.  I started with 8 delay elements so that I could be sure to see a pattern 
in the output, and only a small jitter.

> Currently I'm reading the n-wire to get values out, never the p-wire.
> This means that the rosc-modules generating values in p are basically
> unused. Would it be an advantage to mix p and n (XOR), or should I
> instead for example concatenate n and p {n, p} to get a common word?

Xoring p and n produces something that certainly looks better in statistical 
tests, but in the FFT tests I did, it still shows remainders of the frequency 
distribution of the original signals mixed together.  So my recommendation is 
to concat the values, because that way you get more entropy out of the same 
number of roscs, and you still have a direct observability of the mixed down 
frequency if you sample often enough.

Attached is a FFT analysis, where the first 8 pages are individual p and n 
roscs observed, and the last 4 pages are p^n through the same FFT.

> Changing l to two, increasing the genvar to instead instantiate 2*32
> rosc:s and then xor the n an p vectors should be very straight forward
> and yield 32 bit word where each bit is depends on two separata rosc
> oscillators.

Yes.  For transparency reasons, I favor to have each rosc observable.  This is 
analog stuff, so you have to characterize your devices - the Cyclone V might 
have different properties than the Cyclone II.  So what you need to do is to 
make sure you can sample with a fixed, relatively high frequency and store the 
result into an on-chip RAM, and not depending on a slow serial port that 
accesses things through layers of Linux drivers.  The USB drivers are horribly 
slow (long delays between individual commands), so I do bulk reads of one 
kilobyte, which gives me about 20kB/s with 230kBaud.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: analyse-x1.pdf
Type: application/pdf
Size: 161259 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/tech/attachments/20140528/cc491a9c/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cryptech.is/archives/tech/attachments/20140528/cc491a9c/attachment-0001.sig>