[Gnuk-users] Security of NeuG?

[NIIBE Yutaka]

On 02/16/2015 06:17 PM, Jonathan Schleifer wrote:
> Is simply sampling the ADC enough? I mean, won't there be some
> patterns in the noise? Are there some checks to see that you don't
> get e.g. zeros constantly?

Good questions.

I try to follow the draft of NIST SP 800-90B.  It defines conditioning
component to remove bias from source and test measures to detect
failures.

NeuG implements three tests.  There is a tool in
neug/tool/neug_check.py.  Here is an example output of the tool.  I
invoked it after letting NeuG generate more than 64GiB.

---------------------------------
Device:  014
Configuration:  1
Interface:  1

   Vendor: Free Software Initiative of Japan
  Product: NeuG True RNG
   Serial: FSIJ-1.0.1-50FF6806
 Revision: release/1.0-8-g1722f32-modified
   Config: FST_01:dfu=default
      Sys: 2.0

mode: Conditioned
Repeat errors: 0
PP 64  errors: 0
PP 4k  errors: 0
Total  errors: 0
Repeat max counts: 5
PP 64  max counts: 7
PP 4k  max counts: 44
---------------------------------

It would be recommended to check the output of neug_check.py
periodically.  It would be good for this check to be integrated into
rngd.


Well, I should also address a ISO/IEC document and a BSI document.

    ISO/IEC 18031: Information technology - Security techniques
    - Random bit generation

    Wolfgang Killmann and Werner Schindler, A proposal for:
    Functionality classes and evaluation methodology for true
    (physical) random number generators, Version 3.1, 2001-09-25

NeuG would not be good enough by usual interpretations of those two
documents.  In my opinion, those two documents would be good in
general, but it's not that practical if you try to implement all of
its requirements/suggestions into a single small device.


The possible weakness of NeuG would be: there is no good concrete
theoretical model (of its signal inputs) with which we can simulate
and evaluate extensively.  I believe it's not that difficult, though.
Perhaps, if we will do, we will be able to find improvement for the
implementation.

Another possible weakness of NeuG would be: I don't know well about
possible failure modes of STM32F103 and NeuG.  So far, I have
encountered no failures of STM32F103 which prevents NeuG working.
Your helps will be much appreciated.


Other considerations.  Among Debian community, the product named
EntropyKey is common.  It seems for me that it has better test within
the device itself, and it encrypts the USB communication between host
PC (No, I don't have the product at hand).  For me, it sounds
overengineering.

  * The rngd itself has its own health tests.

  * If the USB communication could be spied, I could say more attacks.
    Well, OK, even if encryption of the communication really makes
    sense, it's not needed to encrypt by the device and to decrypt by
    host PC.  It's just OK for a host PC to have a secret key to mix
    data from the device.


Lastly, could some of you do me favor?  Please update the information
in the Wikipedia for the entry of NeuG.

    Comparison of hardware random number generators:
    https://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators

NeuG is now 1.0.1 www.fsij.org/gnuk/neug_version1_0_1.html
and its speed is about 640 kbit/sec.

I can't do by myself, since I was banned by Wikipedia when I put the
information of NeuG at the page.  They applied a rule to me, that
including a link (to gniibe.org) with a login name (Gniibe) is
prohibited.
--