[Cryptech Tech] Hardware entropy

[Bernd Paysan]

Am Montag, 19. Mai 2014, 15:39:25 schrieb Bernd Paysan:
> Given that 2 roscs give one random bit as result, and we can probably
> sample  them every 1024th cycle, so we get ~50kbps of entropy per rosc pair
> (and a rosc pair takes about one LC slice).  That is with chain length 8,
> I'll try different delay chain lengths, assuming a "the shorter, the more
> jitter" relation.

Ok, here comes analyses for chain length 1, 2, and 4.  Chain length 1 has a 
rather high number of dropouts (with a high DC value but low noise), and is 
likely not oscillating stable (or can't be captured by the DFF), but chain 
length 2 still looks good for most instances; some have high DC values, 
though; confirming the hypothesis that shorter chain length is higher jitter, 
but also more likely not to produce a good rosc.  This is now with a 16 cycles 
sample loop (rng.asm).

Chain length 3 (not attached) is between 2 and 4, as expected.

There are two possible ways to deal with dropouts: Either go for a lower chain 
length, and simply accumulate more values for the same target entropy, or go 
for a higher chain length, and wait longer per sample. Looking at the number 
of plots with high DC values, chain length 4 already has several biased roscs, 
so the idea would be to go rather for chain length 2, and spend the resources 
to build more oscillators, so that the biased ones don't matter much.  Hand 
layout would improve the situation, but I deliberately want to have a fully 
automated flow.

Chain length 2 gives us both significant sampling noise (probably setup/hold 
time violations of the DFF, resulting in metastability) and high jitter noise, 
so to get the maximum amount of entropy out means simply sample often (more 
metastability noise), and let the hash function extract the actual entropy.  
This is then a combination of two on-chip noise sources.

Under commercial development, I would now put 10 devices into a climate 
chamber, and repeat the measurements for minimum and maximum temperature (with 
minimum and maximum supply voltage).  The sampling noise (metastability) 
should stay pretty constant over temperature, because it's matching: fast rosc 
and fast dffs have the same problems as slow roscs and slow dffs.  The jitter 
should go up with temperature (more resistance), but the frequency will go 
down, cancelling at least parts of the additional jitter.  I.e. the design 
should be sufficiently robust against temperature, process and supply voltage 
changes - the tests would be there to prove this hypothesis.

-- 
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-l1.pdf
Type: application/pdf
Size: 110103 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/tech/attachments/20140519/07cc21b8/attachment-0003.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: analyse-l2.pdf
Type: application/pdf
Size: 109889 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/tech/attachments/20140519/07cc21b8/attachment-0004.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: analyse-l4.pdf
Type: application/pdf
Size: 109419 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/tech/attachments/20140519/07cc21b8/attachment-0005.pdf>
-------------- next part --------------
\ triceps2

include regmap.asm

$2000 org
|# rng-start
$3000 org
|# rng-end

$3fe0 org
: boot
    rngp # rng-end rng-start
    begin
	>r
	over @+ @ r> !+ !+
	over over xor
    -until  drop drop drop
    begin again ;
    
$3ffe org
     boot ;;
$2000 $2000 .hex b16.hex        \ print verilog hex for $2000 bytes
$2000 $2000 .hexh b16h.hex      \ print verilog hex for $2000 bytes
$2000 $2000 .hexl b16l.hex      \ print verilog hex for $2000 bytes
$2000 $2000 .hexh' b16h.mem     \ print verilog hex for $2000 bytes, unaddressed
$2000 $2000 .hexl' b16l.mem     \ print verilog hex for $2000 bytes, unaddressed
	 
.end                    \ end of test program
0 [IF]
Local Variables:
mode: Forth
forth-local-words:
    (
    (("\|") non-immediate (font-lock-type-face . 2)
     "[ \t\n]" t name (font-lock-variable-name-face . 3))
    (("macro:") definition-starter (font-lock-keyword-face . 1)
     "[ \t\n]" t name (font-lock-function-name-face . 3))
    (("end-macro") definition-ender (font-lock-keyword-face . 1))
    (("0<if" "-if" "cif" "-cif" "u<if" "-until" "cuntil" "-cuntil"
     "-while" "cwhile" "-cwhile") compile-only (font-lock-keyword-face . 2))
    )
forth-local-indent-words:
    (
        (("macro:") (0 . 2) (0 . 2) non-immediate)
        (("end-macro") (-2 . 0) (0 . -2))
        (("0<if" "-if" "cif" "-cif" "u<if") (0 . 2) (0 . 2))
        (("-until" "cuntil" "-cuntil") (-2 . 0) (-2 . 0))
        (("-while" "cwhile" "-cwhile") (-2 . 4) (0 . 2))
    )
End:
[THEN]
-------------- 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/20140519/07cc21b8/attachment-0001.sig>