[Gnuk-users] TRNG output

[NIIBE Yutaka]

Hello,

Thank you for your question and your reasing the code.

On 08/24/2015 07:27 AM, Kurt Roeckx wrote:
> I recently got myself one of those boards acting as TRNG.  I
> wanted to verify how good the randomness is, but I'm a little
> confused by the documentation and code.

I admit there are some estrangement between documentation and code.
Major reason is I am not good at writing document in English and it is
somehow difficult for me to explain the technical detail in English.

Even I found difficulty writing in Japanese.  I am writing a document
in Japanese.

    Using NeuG on FST-01 (in Japanese):
    http://no-passwd.net/fst-01-neug-handbook/index.html

My intent is it will be translated into English.

Nevertheless, I try to do my best for the code and the documentation.

Your help, like this question is appreciated to improve the situation.
While it takes time, I answer what I know.


> The code talks about 2 ADCs and a total of 4 inputs (Vref, temp,
> Vdd, Vdd).  I understand that it's a 12 bit ADC.

Right.

First of all, the vendor information is available at:

    STM32F103TB:
    http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1031/LN1565/PF250484

With the tab 'Design Resources' clicked, you will find the document
RM0008, which is the reference manual (CD00171190.pdf).  In the chapter
11, ADC is described.


> I've been looking at them in EP_ROUND_RAW_DATA mode, and I see
> some strange results.  I'm not sure I really understand what is
> happening, but I get back groups of 32 bytes, which seem to be
> 16 12 bit values, or each input 4 times sampled.
> 
> It seems to be the more times you read it the less noise you get.
> Looking at the values I get you're not actually waiting until the
> ADC is done converting and the noise is actually caused by timing
> differences and not by quantization noise?
> 
> Can you explain a little more how it works?

The code for ADC is in neug/src/adc_stm32f103.c.

Note that it is compiled with the configuration of
DELIBARATELY_DO_IT_WRONG_VREF_SAMPLE_TIME and
DELIBARATELY_DO_IT_WRONG_START_STOP enabled.

In this configuration, I think that the data we see is not the
measurement of the accurate value of those analog inputs.

In the reference manual, it is recommended to use ADC_SAMPLE_239P5 for
sample time, but current code uses the minimum sample time of
ADC_SAMPLE_1P5.  Also, I think that (for accurate value measurement)
it is better to run ADC continuously (and just read out measured data
when it's needed) but the code let ADC start and stop each time.

I chose running ADC in this way, because I found I can get more
unexpected values in this way.


We can check by the tool neug/tool/neug_check.py.  When we can get
enough "noise" we will see less errors.


It is possible to configure with
DELIBARATELY_DO_IT_WRONG_VREF_SAMPLE_TIME and
DELIBARATELY_DO_IT_WRONG_START_STOP disabled.  Or, it is possible only
use LSB of each sampled data.  I just use any data bits which are not
under control by anyone.


Formal model of this sampling data could be built easier if
DELIBARATELY_DO_IT_WRONG_START_STOP is disabled and we only use LSB of
each sample.

For such a formal model, I think that it could be the one described in
Fabio Pareschi's PhD Thesis.

    Fabio Pareschi
    CHAOS-BASED RANDOM NUMBER GENERATORS: MONOLITHIC IMPLEMENTATION, TESTING
    AND APPLICATIONS
    http://amsdottorato.unibo.it/467/1/PhDThesis-Pareschi_Chaos-based_random_number_generatos.pdf

Same idea is described briefly in the paper like this (Rovatti and
Setti are the tutors of Parenchi):

    Sergio Callegari, Riccardo Rovatti, Gianluca Setti
    Embeddable ADC-based true random number generator for cryptographic applications exploiting nonlinear signal processing and chaos

http://www.researchgate.net/publication/3319163_Embeddable_ADC-based_true_random_number_generator_for_cryptographic_applications_exploiting_nonlinear_signal_processing_and_chaos



I would like to keep current configuration as long as it works well.

If someone cares formal model, it would be good to have compile time
or runtime option to prefer rigid configuration.  I don't know if it
makes sense.
--