[PATCH] Adding diversity for security

[Robinson, Paul]

> -----Original Message-----
> From: Alp Toker [mailto:alp at nuanti.com]
> Sent: Friday, January 24, 2014 1:00 PM
> To: Robinson, Paul; Sean Silva
> Cc: Joe Abbey; reviews+D1802+public+4ebeb8c9d612540c at llvm-
> reviews.chandlerc.com; Andrei Homescu; Per Larsen; Luc Vitashack; llvm-
> commits at cs.uiuc.edu; Julian Lettner
> Subject: Re: [PATCH] Adding diversity for security
> 
> 
> On 24/01/2014 18:48, Robinson, Paul wrote:
> >>>          Also, at the very least, adding the RNG should be split out
> >>>          into a separate patch.
> >>>
> > Amen to that, brother.
> >
> >>>      Why? We usually land supporting facilities together with the
> first
> >>>      use for ease of review and testing.
> > Sometimes.  Other times they're done independently.  Depends on the
> > size and complexity of the pieces.
> >
> >>>
> >>> Especially for integrating with foreign code, we do separate patches
> >>> (even sometimes separate discussions on llvmdev), consult e.g. the
> >>> additions of MD5 and zlib.
> >> The RNG in the patch is a small class with LLVM's existing MD5
> >> implementation being the only dependency.
> > But the choice of MD5 for this purpose is inherently suspect.
> 
> I think there's value in having a callback mechanism to provide chunks
> of entropy, as a point to work on in-tree. There are a couple of
> features that would be able to make use of application-provided entropy
> and it'd fit well with LLVM's library design.

As long as the *stated* expectation is chunks of some sort of entropy,
rather than crypto-quality entropy, and MD5 is being used solely for
convenience, then okay.

> 
> The application can then link into vendor-specific entropy or OpenSSL as
> needed if a higher grade of security is needed.
> 
> As a built-in default providing a reasonable level of reproducible
> unpredictability I'm satisfied with the use of existing MD5 facilities
> in LLVM.

That's fine.  My personal suspicion is you could get equivalent RNG
statistical parameters, or better, for less computational cost; but
that would take engineering effort to investigate that nobody here 
probably thinks is really worth their trouble.

> At some point we're probably going to want SHA1 for other
> purposes as well so that can happen when it's ready.

Why switch the RNG?  My understanding is that SHA1 is not really 
faster than MD5.  And given that it's yet another digest/hash 
algorithm, all the same fundamental objections would still apply.
MD5 isn't going away anytime soon (DWARF specifically requires it)
so I can't see any point in switching the RNG to SHA1.

--paulr

> 
> Alp.
> 
> 
> >
> > My own security days are over a decade behind me but it's not hard
> > to find serious objections to using a hash function as the core of
> > a PRNG.  F'rinstance [1] goes into some detail, once you get past
> > the list of objections to the original post/question on that thread.
> > I haven't found any published statistical analysis of an MD5-based
> > RNG to put the nails in the coffin but I am persuaded that it's not
> > such a great idea.  It is _specifically_ _not_ a crypto-level RNG.
> >
> > Most of the motivation to use MD5 in this mode seems to boil down
> > to the obviously flawed syllogism:
> > (a) MD5 was invented by a crypto guru
> > (b) crypto == good
> > (c) therefore MD5 == good for purposes other than what it was
> >      designed for
> > This is a general critique, lots of people (who aren't crypto or
> > security trained) tend to think this way, as evidenced by the
> > number of MD5-based RNGs you can find on the web.
> > --paulr
> >
> > [1] http://security.stackexchange.com/questions/21277/create-a-
> variants-of-md5
> >
> > P.S. I'm not taking a position on the value of the NOP feature, just
> > mouthing off about the RNG piece of it.
> >
> >
> 
> --
> http://www.nuanti.com
> the browser experts
>