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

Joachim Strömbergson joachim at secworks.se
Fri Feb 7 09:38:24 UTC 2014


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

Aloha!

Randy Bush wrote:
> As for the specific choices: the part about injecting seed values 
> scares me, since that’s an open door for malware to inject known 
> state.

Inject as in injection of test values in the production system? It is
quite possible to remove that kind of functionality. It is one of the
features people has been asking Intel to add into RdRand in order to
make the Bull Mountain black box a little bit more opaque. I therefore
saw this a way for us to provide control and thus build trust in the
Cryptech system. Be able to sample raw entropy sources and in a
controlled way inject test values into the CSPRNG and see that it
functions as expected.

The normal operation of the system should be suspended when this is
happening to prevent injection attacks leading to keys being generated.


> Normally, I’d suggest using a NIST-standard PRNG; right now, that 
> scares me a bit, for some reason… For ChaCha, though, I’d like to
> see published analyses of its output randomness; the lack of that was
> one of the early warning flags for RC4.

DRBG_CTR from SP 800-90 should be a pretty conservative choice then.
Regarding ChaCha it is true there aren't that much analysis on it (yet).
And we could use any other stream cipher, hash function or block cipher
in proper mode we want. Some of them are are easier and more compact to
implement in HW than others.

The reason for suggesting ChaCha is that it is based in Salsa20, which
has been analyzed quite a lot through the eSTREAM project (where it was
selected as one of the ciphers in the portfolio). And also because it
has been designed to have little side channel leakage and is very fast
even in slow and cheap FPGA chips. IACR ePrint Archive lists only two
papers with analysis on ChaCha:

http://eprint.iacr.org/2012/065
http://eprint.iacr.org/2007/472

And then of course DJB provides some analysis himself:
http://cr.yp.to/chacha.html

My take on the state of ChaCha is that it is fairly well analyzed and
has provenance from Salsa20, HAIFA and the ARX constructions that makes
it pretty trustworthy. That is why we are proposing it as a replacement
for RC4 in TLS.

https://datatracker.ietf.org/doc/draft-mavrogiannopoulos-chacha-tls/

But again - we as a team must decide on what we will use as CSPRNG.
DRBG-CTR based on AES-256 is a good choice.


> “Ample time to collect and curate” randomness is not a feature,
> since it means that this state is lying around the system.  A major
> point of injecting new randomness is to deal with transient access
> by attackers.

It is a feature if we have a slow entropy source and would have to stall
the CSPRNG due to lack of collected entropy to seed it with. I'm not
suggesting that we should build huge pools of collected entropy.

And lying around suggests that it would be placed at different memories
in the system when it in fact would be a few small memories inside the
FPGA (or a MCU if using a SW solution). Unless we do a faulty design,
the active tamper proof fails and we (or implementer) retain a JTAG
interface these memories should be physically inaccessible.

If the collector-mixer-structure used in a lot of RNGs are to be
accepted as a good general strategy, then collecting entropy and having
it laying around in pools is part of the solution. We will not be doing
anything different. In the Fortuna, having several pools and thus
collecting a lot of state is part of the security feature since it
protects agains injection attacks. At least according to the Fortuna
designer Bruce Schneier.

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

iQIcBAEBCAAGBQJS9KmQAAoJEF3cfFQkIuyNSUAP/jxMgwgryBnIkz1d5WyrLu2i
D3xP+lgkmJqnObWQaYCANbU07QE5trEC3IVRYUVwp417B16QbH7DDq66gynaQ13h
y36G9eL6aiLURDpj6ABacrw5GzS0uXVNAX8Ci7Vn2de7U6QtRCtCxTbiMoZnUycy
359g5scN/ueAsKKvFqllbmSBAL7iRldxHantRcipffvzwLFPaHIJFF/EVhvdjjAn
yvs9xugrkHEKQ2y1W095y/wmk+hNZOiSKQDu9P8RTLZk9s7dUeL3q1xStbmkaWRl
Ed9yKNM1wAEjAcOnUGNcfdPcuHrKj5NSAYoFPoATJIYmKqfFA+7YalxEvSgjmL/a
s9Tw8OsaKcpb2Iq+9t1pQv9UR8h9cATaMSOXfB3Hl+/X7CnXzVwDkdCvd5w0801Q
4m8Iqiac/hdJuvv2YD9wnRSfy5+71O5hEWw1DtsoRl8g21EAAruLIbpk+wJ/8JfV
7GvIdGMqzRd9Y+coXRNNECA6diqfSX0zphap0Q997yhkRjXOYEc7aEl/4ivT3fXq
VbakX3+tcvtnGlBjXKwkrLjhbYDSLtrRHwMOeUnpBfKFro/yWWYYWMA+Ysh4dOpX
d++6oq8EJUXnx9/NFDBunrkyivVMW27l/Lof63w4Lb2EmHgZZqpCM0kZ61ra32g0
iYNhgPavXbQJIh/9kqcL
=LmhW
-----END PGP SIGNATURE-----



More information about the Tech mailing list