[Ach] Random number generators (was Bug/Ba in OpenSSL)

[Adi Kriegisch]

Hi!

> On 26 Nov 04:43, Ralf Schlatterbeck wrote:
> > I agree on the other assertions that HAVEGE can be used to augment the
> > Kernel random number generator in certain situations where your random
> > sources are limited. This occurs mostly in embedded devices like WLAN
> > routers etc. For these devices HAVEGE will improve your random-number
> > source.
It is probably helpful to distinguish between the algorithm and the daemon:
haveged is most probably meant in this case.
 
> FYI:
> http://lists.randombit.net/pipermail/cryptography/2013-November/005818.html
> 
> Sounds like testing it is crucial before adding that to the paper.
Hmmm... or probably reading what is in haveged since v1.5:
http://www.issihosts.com/haveged/ais31.html

btw. I did some tests on MIPS and PPC with several megabytes of
'randomness' -- in all cases ent showed that the entropy is just fine. I
probably could test on a SPARC too, but I guess that will not be necessary.

Quoting from current README.Debian of haveged: (The complete readme may be
found here:
http://anonscm.debian.org/gitweb/?p=collab-maint/haveged.git;a=blob;f=debian/README.Debian;h=9ac011fe66ccaf34091a1b1ec643a7e1af761e78;hb=HEAD)
  | When asked if the issue also applied to haveged, Gary Wuertz  haveged
  | author replied:
  |
  | First, there are significant differences between the polarssl and haveged
  | implementations of HAVEGE. In general, haveged works much harder to provoke
  | timing variations in the host (larger collection buffer, tuning collection
  | code and walk table to the host L1 caches). See comparison below.
  | I think items d) and e) in the comparison are items where polarssl is
  | particularly weak.

...and the parts of the comparison in question:

  | d) Collector warmup
  | 
  |  * PolarSSL: 1 fill
  |  * haveged: 32 fills plus self test
  | 
  | e) Run time testing
  | 
  |  * PolarSSL: none
  |  * haveged: Continuous and start-up AIS-31 tests (configurable)

And once more HAVEGE is an algorithm that was implemented by eg polarssl
and where they failed to handle certain stuff whereas haveged is a daemon
that *injects* its random bits into the kernel's entropy pool.

Quoting the mail on the crypto list above:
  || Also, the entropy estimator supplied with Havege is (was) broken. We
  || tested Havege in a system simulator where we could manipulate/force the
  || TSC which means that Havege generated predictable values. The estimator
  || happily reported good entropy.
I think this is referring to the link cm came up with. This is fixed in
haveged beginning with version 1.5 by adding AIS-31 tests.

  || On an x86-based server you can use Havege, but use it to feed
  || /dev/random, not as a RNG directly. The same goes for Jytter.
This is exactly what haveged does when you just start it up an leave it
running...

There is a major drawback in haveged on embedded devices however: Its
memory consumption -- by default it takes 4MB of Ram. Probably OpenWRT devs
already dealt with that?!

-- Adi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20131127/ba51b144/attachment.sig>