this week's NIST workshop

[D. J. Bernstein]

Can someone attending the Random Bit Generation Workshop 2012---

http://www.nist.gov/itl/csd/ct/rbg_workshop2012.cfm

---post here a summary of the highlights for those of us who aren't able
to attend?

---Dan

[Jon Callas]

Please.

I really, really, really wanted to be there, but life did not cooperate.

Jon

[Jean-Philippe Aumasson]

Meltem told me that she will take some notes for us.

> --
> You received this message because you are subscribed to the Google Groups "Randomness generation" group.
> To post to this group, send email to randomness...@googlegroups.com.
> To unsubscribe from this group, send email to randomness-gener...@googlegroups.com.
> Visit this group at http://groups.google.com/group/randomness-generation?hl=en.
>
>

[Jean-Philippe Aumasson]

Here's notes that Meltem took and kindly agreed to share with us:

////

NIST hosted the Random Bit Generation Workshop on December 5-6, 2012. There were around 40 participants and many lively discussions.

The SP 800-90 series were the focus of the workshop: SP 800 – 90A that specifies the approved Deterministic Random Bit Generator (DRBG) mechanisms; SP 800 –90B that addresses the entropy sources needed to seed the DRBGs; and SP 800 –90C that specifies constructions for creating random bit generators from entropy sources and DRBG mechanisms. The discussions on the first day of the workshop were mainly about SP 800-90B, whereas those on the second day, validation was discussed.

In the workshop, most of the discussions were about the entropy sources: how to design entropy sources, how to collect raw data from the noise source, how to test for validation and how to detect the failures were the main issues.

As specified in SP 800-90B, entropy sources have three components: the most important component is the noise source that generates the raw (unprocessed) data. There were some discussions on what we mean by raw data. (e.g., if the output is the XOR sum of many outputs, can we consider this as raw data?) The hardness of collecting raw data (especially consecutively) and generic evaluation and testing of the noise sources were discussed. The consensus on how to evaluate the noise source is to expect designers to provide justifications for their designs and an estimation of entropy by trying many iid and non-iid tests. NIST recommended using sanity checks (compression and collision tests) to make sure that something hasn’t gone wrong. The effect of restarting the device, changes in temperature, humidity etc. were also discussed in the workshop.

The second component of the entropy source is the conditioning component that is intended to improve the statistical properties of the output. This component is optional. There were some discussions on the necessity of the component, and the use of unapproved conditioning functions and non-cryptographic conditioning functions. One suggestion was to use universal hash functions as the conditioning function. It was emphasized that constructing conditioners with an iid assumption should be avoided. There were some disagreements on how fast/efficient the entropy source should be.

The third component of the entropy source is the health testing. These are continuous and simple tests to detect major failures of the noise source. NIST specifies two health tests: repetition count and adaptive proportion. However, the designers are encouraged to design similar tests based on their system and demonstrate that the tests are able to capture similar weaknesses. It was noted that the tests introduce a bias on the output sequences.

////