[Cryptech Tech] trng ready for play

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Bernd Paysan wrote:
> Am Dienstag, 7. Oktober 2014, 07:18:56 schrieb Joachim Strömbergson:
>> Aloha!
>> 
>> Bernd Paysan wrote:
>>> Feeding in a full block of known stuff into SHA-2 as key for
>>> ChaCha however does reduce the entropy (we only have the counter,
>>> which isn't reset at reseeding).
>> This is incorrect. ChaCha is reseeded with:
>> 
>> (1) New 256 bit key (2) New 512 bit block (3) New 64 bit IV (4) New
>> 64 bit counter initial value.
> 
> I'm not sure if I like this.  Full reseeding means that an attacker
> who managed to weaken (but not completely defeat) the entropy sources
> may guess that state.  Let's assume the attacker managed to modify
> the FPGA so that the ROSCs all oscillate in harmony, or by modifying
> the synthesis tool to collapse all 32 ROSCs to only one ROSC, like
> Xilinx's tool does without hints - they still jitter, but it's one
> bit of entropy per 32 bits; and the attacker controlls the diode as
> well (maybe in a way that it is considered dead, and the reseed
> switches over to the ROSC).  Let's say, the overall entropy of 
> reseeding is still 28 bits; that's within reach of brute force
> attacks, but out of reach to people who just check if each first
> random block after reseeding is different.

First off, if someone is able to do all those modifications we are
royally screwed anyway. At least at the moment, we do need to start
looking at ways of doint assured toolchain and builds for FPGAs. But
that is another track.

You are basically saying that an attacker is given the ability to kill
both entropy sources and still having the TRNG feed applications,
assuming that any alarms are ignored.

But what you are missing is the difference between what the mixer is
doing and what the csrpng is doing. A full reseed of the csprng does not
mean that the state of the mixer is restarted.

What I do is add 1024 bits and perform next_block processing in SHA-512
to get 512 bit seeds. That means that any 512 bit block of seed depends
not only of 1024 new bits of entropy, but also on all previous SHA-512
operations. An attacker must know this internal state too in order to
predict the seed values used to initialize the csprng.

If you do a reset of the FPGA this state is lost. But we are fairly
rapidly moving into an area where alarms should have been started to
loudly warble.

A bit more likable, yes?


> You can avoid this single point of failure by not reseeding enough
> bits so that each reseed will add entropy to the pool, but can't ever
> take entropy out.  E.g. if you want 256 bit "safety margin" against
> this attack, keep 256 bits of the bit block (no need for collission
> considerations, as the attacker here is supposed to be unaware of the
> internal state).

Or do this in the mixer, which is basically what I'm doing - Adding 1024
bits of entropy and pulling 512 bits out.


> The actual ChaCha algorithm specifies that the 512 bit block is
> created form the key, the IV, the coutner initial value and a few
> constants;

I think my description of the csprng and seeds needs to be clearer. Your
description of how ChaCha works is exactly how I use it with blocks
generated based on key, IV, counter. The 512-bit block is the data block
that the generated blocks are XOR:ed with. It is my "data block" in a
stream cipher operation. It could be all zero too but setting it to a
random value adds internal state an attacker has to guess.

The random seek functionality is why I can get to arbitrarily high
random number perdformance by instantiating more parallel ChaCha cores
and have then generate values interleaved by stepping the counter +N
steps (with N ChaCha cores) instead of +1

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJUP8oKAAoJEF3cfFQkIuyNNS0QAK/DvR0VpgXq77NEAddi351I
0HHjRuBx719qvxtVgEy8N/vyhxVoppHfJCGLBiWRK+qKtd+D2Ki2qEYk+/4GVyY0
pnPli6VvTvF0Dgt4B+1TxEQQ8wZi+ZG11ywOYZSQC4VQ0BBe3w6f2tCTWw7UCPLT
PAFGLlBrNOgNv6RO8rS6RpECJf8HYBIDnOFU7j9wDnwPljd/GiHgRHriQNftE3u9
aundEs8hUqevL66yh4NjZfmOrjern95N1b0r62p8rivI7M7n7q8Osj8C0fd44ppr
Wwoi8p74UWVLDiFyA0L8xTVg4war3vzMIN+vGgprfQQOoShFNAW7oOVaKHokdZOb
+VTL935I2KPRQCgqsTcOCc9auqkQ/T9a5mnMkytAXgec591iMnQs23b5uEFjQWd3
1tSLGLfFBchzVyn2mWDQgGmExiKUJxMo5XvYVFkYHTOKlYVH4rNkTnyMh0LO5rpo
WtJCtm7RKl9M2zcTvkOyk5IDqafam/TfnaizMryyGluulPb0C5FrsIQ0UItf1Ybj
vUL+WvqrVs0aQcGUJi9zIrGYoxY8VSeaIs1NwIUC+1xrd+3drKTzHc7SLECgdcRY
+NyGnlL+dC/Z5SKN8gj7L5ikAA+f+svBd/oLqVaQadU+5wWMc9wVGWH8l6QD4J7V
0yELk636MEnZObPibt/h
=pL/C
-----END PGP SIGNATURE-----