[LLVMdev] Adding diversity for security (and testing)

[Todd Jackson]

> > We would also include a secure random number generator which links
> > against OpenSSL. This would of course be an optional module disabled
> > by default, but is necessary so the randomization is cryptographically
> > secure and useful in security applications.
>
> I am not sure why you need this feature.   You can provide LLVM with a
> SEED value that can be controlled from the command line.  A wrapper (such
> as a build-script) can control this value.


(disclaimer:  I was a member of Stephen's research group and worked on this
project.)

To my knowledge, the pseudorandom number generator in LLVM is not
cryptographically secure.  In this use case, the intent is to make it
difficult to get the random number seed or the generator's state at any
point in the random number stream by looking at the output.  If the state
of the generator can be compromised, then an attacker can predict the
output of the generator by playing it forward.  If an attacker can play the
generator forward, then the attacker can reproduce the rest of the
executable, including the randomized components that are no longer random
to the attacker.  Reproducing the executable means that diversification
isn't going to work because the attacker can plan around it.

For reproducibility, such as for debugging, a pure software generator is a
good idea.  This also prevents blocking read operations in the generator,
slowing down the compiler.  Software generators can be optimized for speed.
 These are reasons to avoid /dev/random et al.

Personally, I think it is necessary to go for the strongest random number
generator possible.  Cryptographically secure pseudorandom number
generators have good properties that make them resistant to compromise.  In
the case of the generator I think Stephen is proposing -- a generator based
on running AES-128 in Counter Mode and described in one of NIST's documents
-- the security comes from strong crypto building blocks, while still
suitable for embedding in a  compiler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130826/5464f79f/attachment.html>