[Ach] Bug/Ba in OpenSSL

Philipp Gühring pg at futureware.at
Tue Nov 26 00:55:44 CET 2013

Hash: SHA1


> In short:  use it as it is setup, or write your own.  There isn't a lot of middle ground.
> I absolutely agree. RNGs that get shipped by operating systems are
audited heavily, custom RNGs are not. As stated before: I haven?t found
a analysis/research paper on HaveGE, the original paper describung the
algorithm is years old. This does not seem to be well audited. Proof me

I collected several HAVEGE submissions on my random number analysis
service, and all of them were good:
To me that says that HAVEGE isn?t completely broken, and provides high
entropy, as it should.
I did not audit it for any backdoors, but I think it should be far
better auditable than RdRand, and it should be more difficult to hide a
backdoor in there.
I asked on the cryptography mailinglist that more people should analyze
and research it, since I believe in the concept behind it.
I believe that the concept of HAVEGE is superiour to most other RNG?s:
* since it does not rely on external interrupts, and therefore can? t be
easily attacked from outside (and any inside that runs code on the same
CPU can possibly do much more damage anyway),
* it seems to provide far more speed than the other concepts like
external interrupts
* it?s available on most computers, since all computers I know have a
CPU built in and well-connected. (in contrast to things like soundcards,
lava lamps, ...)

So a /dev/random kernel module, that takes entropy from HAVEGE, RdRand
(and equivalents on other CPUs), and interrupts, AND MIXES all of them
together, should be the optimal solution from my point of view. HAVEGE
should be ported into /dev/random (if they did not do so already, I don?
t know for sure, some comments from Ted Tso seemed as if they did)
Until HAVEGE is implemented into /dev/random natively, I would suggest
to use HAVEGE to mix additional entropy into /dev/random (I think that?s
what they are doing, but I haven?t made sure myself yet) when you really
need the speed of randomness, or to use plain /dev/[u]random, when it?s
speed is sufficient.

Best regards,

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the Ach mailing list