Hi!

The interesting discussion induced me to look again to the actual report [1]. When I initially did, I came up with the impression that the RNG design is sound to the extent that a) any system based on sampling an unpredictable physical phenomenon has some intrinsic limitations, and b) you accept the NIST SP800-90 architecture. Furthermore, one has to read between the lines and make its own opinion.

Here are the main questions that I had in my first (and again in my subsequent) quick reading :

Q1. Do you like a system where the deterministic algorithms (conditioning, DBRG) are exposed only at the pseudocode level?

Q2. If you want to build a production system with it, how do you define "fail-safe"? Stated otherwise, if the RNG signals its malfunction to the software, as a system integrator, how are you going to handle the negative customer perception that the the "best commercially available RNG" simply turns off the customer production system?

Q3. Do you agree with the report authors when they write (end of section 3.2.1) "Also, while such failures can cause the design to behave briefly as a cryptographically-strong deterministic RNG, this should not result in any loss of security." ?

Q4. How do you get confidence that production parts are as good as the parts used in the report review?

None of these are specific to the Intel RNG being reviewed; any serious RNG arrangement based on sampling an unpredictable phenomenon might trigger the same set of questions.


Regards,

[1] "ANALYSIS OF INTEL’S IVY BRIDGE DIGITAL RANDOM NUMBER GENERATOR", prepared for intel by Mike Hamburg Paul Kocher Mark E. Marson Cryptography Research, Inc., March 12, 2012 http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/

--
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography

Reply via email to