[Cryptech Tech] RAM as source of entropy

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


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

Aloha!

First: Thanks for your thoughts and suggestions on the entropy source
solutions.


Василий Долматов wrote:
> Due to extreme importance of the quality of randomness for the 
> security of any cryptography the random source should be extremely 
> reliable, being the cornerstone of the cryptosystem.

Yes, there we are in agreement.


> The only proper  source of randomness now is based upon usage of the 
> noise diode.

Is it?

There are imho several proper sources of randomness, the problem is how
cumbersome they are to use. Radioactive decay, cosmic background
radiation, hall effects. NISTs for example (claims to) use quantum
entaglement effects for their randomness beacon:

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

The big problems with a lot of these sources are that they are
expensive, big, cumbersome to integrate and relies on a lot of support
structures that can fail and/or be manipulated.

The noise diode is commonly used in low cost environments because it is
pretty easy and cheap to integrate. But it is sensitive to ambient
temperature and the analog circuit can end up (and has been forced)
close to saturation which affects the entropy quite badly.

YubiHSM uses avalanche noise, but others for example based on Exar
(HiFn) design does not, but instead on jitter from multiple internal
oscillators within the ASICs. And I believe IBM at least in one instance
have used radioactive decay in a (shielded) HSM.


> If it is necessary to have couple entropy sources (I can see only
> one reason for it - the redundancy - but, being sincere I cannot
> imagine the necessity of entropy sources being redundant in such
> device, if source fails, it is much more simple way to throw out
> whole device and replace it with the new one), that could be done by
> placing two _identical_ sources into the device.

This is in direct contrast with the discussions going on at
@cryptography, the DJB list etc where the multiple sources are seen and
suggested as a mechanism to add difficulty on any attacker due to the
need to manipulate/force several sources into predictable state
simultaneously. Not kill the source, just force it to have some bias or
patterns that can be predicted. And for this reason these sources would
be based on two different principles. Diode noise and something for
example. To me, two identical sources sounds very much like security
theater.

My thoughts on the entropy sources for Cryptech is two support one or
more sources. And in our example design we use two sources, but provide
source templates and documentation to allow users/implementers to extend
to as many and different sources as they see they need. We won't put a
requirement on having two or more _different_ sources, but will
recommend having at least two different sources.

Furthermore my thinking is that we should try to have one external
source and one internal source of entropy. Internal as inside the FPGA.
There has been some really interesting research presented at CHES the
last couple of years on entropy source designs used inside FPGAs.

The reason I started looking more into the external, dedicated RAM
solution is due to the less reliance on analog circuitry tuning to get
good avalanche effect. The SRAM based solution would be easy for a lot
of users to implement and test. And cheap.

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

iQIcBAEBCAAGBQJS9KDjAAoJEF3cfFQkIuyNBeEP/1fMjPcbkgaheUjwk3cLydVW
WkufeCa/x+8UlP+POphZZbweFBoRinEjnPeonmHQ17mgIO1K6EzvkWdCtR5Yvsu2
dFWGpbDmOOdYpHOzwbMUC4Q/8eVs+IpEM0TweR6/GdJr3OAimWFmBlekR9cLcOni
W5pKIeN3ED+0WMeOxTsrLtecE/ke/c3E+jVrDpgos+jfMFxdir9NUg3Elt0ijMQq
iTPko373UWW2pNqaD2eEdHS+52CviUAMxphsA6nnHsKwOhz8mUmhvLOXR3IQKRCX
oJgw7u+gP1a28SOV0BXtZ1d//HfJlx7+ySiKMrMp7X33A3OuM4ScQhU7Qt35yxpr
V76ey2enjzykHTgiOGAScxvrr89PFBkC0KJY16gOqQmks6uSbOq3bt4mRQLchXqR
A1IBbGUox0njuBlYusiN+JFWqOU4W0VQQR4/unvj3PeF55lKI08xZZk5zJ5KGWED
IJYYgovuLAkp232JkXtwWBaPXUjxoGytv9cToQh9K2VN4u6lGbhausw/DVf2yVEs
997YHcjQ0y2gumWFNlHEN55VeAYzi3OfFM2AgjDCo5LlPoIzQavpBzhHtJG2RxPd
ROfyNt5cllnRotJlrzkfr2Xfu9OBHZiMawCbxiJMUgyctPMPk31WF7d1GPU0MuSt
CuZjpLut5b3GyRN2TQe4
=8IiN
-----END PGP SIGNATURE-----



More information about the Tech mailing list