[Cryptech Tech] Some thoughts and questions on the RNG strategy

[Joachim Strömbergson]

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

Aloha!

Thank you for good comments and suggestions.

Steven Bellovin wrote:
>> OK -- I'll propose a requirement without giving a solution: have a 
>> high-assurance way to make sure this is disabled.  That is, it
>> should be all but impossible to run normally with this feature
>> enabled, and no compromise of other software should allow it to be
>> enabled without disabling everything else.

Yes. As much as is ever possible. And since we are doing the HW we can
do quite a lot. We can block read attempts from the normal read random
numbers, assert error signals if this is done and pull interrupts. But
on a more strategic note I would appreciate your views on the test,
verify functions I've considered for the RNG.

What I'm trying to provide are mechanisms that allow the rest of the
system and the users to both during implementation as well as during
operation monitor and verify that the RNG functions as expected. This
means adding mechanisms to observe the functionality, get health status
signals as well as being able to force tests of the functionality. What
I (at least orally) have suggested are things like:


(1) Having on-line testing for each entropy source. This on-line testing
would be similar to some of the tests in BSI AIS3 and NIST SP 800-90.
For example mean value, variance, uniform, monobits, run lengths. The
test result would probably be condensed down to pass/fail, but could
possible have a pass/fail for each test as well. The purpose of the test
system is to provide a means for the rest of the system to check if a
given entropy source is not totally broken.


(2) Allow the rest of the system enable/disable a given entropy source.
Or should it be automatically disabled if the tests in (1) shows it to
be faulty. The purpose is to be able to block influence on the generated
random numbers from a suspect entropy source.


(3) The ability for the rest of the system to extract raw data from a
given entropy source. The purpose is to be able to do thorough offline
testing. The extracted raw data should NOT be allowed to be used for
random number generation.


(4) Testing of the CSPRNG by allowing injection of seed values and then
generating random numbers (this is what we discussed above). The purpose
is to allow the system (and users) to verify that the CSPRNG functions
as specified. One variant would be to instead of injection have a
defined, fixed set of test vectors that are used. This blocks the
ability to inject a arbitrary value controlled by an attacker.


I would really appreciate any comments and your views on if/how to
provide trust in a RNG as well as on these different mechanisms. Which
do you see are good, bad, needed? And what scares you about them? We are
early in the development and nothing is set in stone. It is much more
important to get this right and provide a system that can be trusted
than having something working a day or two earlier.


>> The link to Salsa20 is reassuring.  djb's analysis should, of
>> course, be discounted...

;-)

It might be worth noting that the OpenBSD project replaced the RC4 based
PRNG with ChaCha at the end of 2013. (It still retains the arc4random
name though.)

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/arc4random.c?rev=1.26

- -- 
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/

iQIcBAEBCAAGBQJS9ekKAAoJEF3cfFQkIuyN9osP/1ggc6xs6KIxPkP1ODJr/wZW
2+CMjJbuvUaMuatLEXeWRhoNxtKIHBXgwEeAs12pzZdoeEav2PRNERMoRP+00239
nWMqFRIjwqyjMymLlp/cx168thQoQIRiPU7GL1hnBxksl3D/z7vfb7GcPBSXO7DO
yRU4qq9cMVavxIzeGzx7vrZfYT5DmyHrXZBKYkn7nipF5W1Wwe0AdRvD7YvUATGY
C13BU8/nZ5qojXckzLDMj2UCvL4bqjYegImKSxNx2HekQzbOjvzH12iK2mjY54+4
Zk/exA83s+lu2DnVbpoePK8HksafxmtKAw8c2MXug4Q/a2Ek56DkKye8h+vlbEma
raQB4EqJNYmpUdlTQidFhVevPwjk16UEVqMru6oFZsBc7BBoOoBJ2IY/obM/Ik+q
5nVK9F5W1W1IxV7RyMaBgFxfLqvZu9JJECK1/OKmiaxNbmhh1lZ+msLY1RR1iPsV
fcWLScrEq9amVMDBWaktehmqMW/k9omXdvyepcXVqNYznLkFIdwERm8sHr0JscON
gXA+AzKzD4Btc2Vi08/mIdB5VnysT6NJ3oAyoxWLQP8YdraEpqKZceUUj/vCdDhD
DArYKIEQYNlHJ8fUJHkTmQVIqMhmZ/iW/BwyJbcwM1ro3CLUcVaQvAL1bOXGEPhA
R8JpONIrpQmLOMpdM6V6
=vd1u
-----END PGP SIGNATURE-----