Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] How do I add entropy?



> From: Kent Borg [mailto:kentborg at borg.org]
> 
> I am not wedded to the xor decision, and I would not have dreamed it up.
> But looking at NSA's backdoor as an engineering problem, that xoring
> looks like a really hard thing for them to break. The secret silicon
> would have to be field upgradable to match specific kernel versions.
> There have been 32 changes to random.c in Linus' tree so far this year:
> random.c itself is a low-bandwidth entropy source!

Good points, and agreed.  I would have phrased it differently:  Put really simply, it would be difficult but distinctly possible to design a chip which would track the internal state of the linux kernel PRNG in order to undermine it.  However, I think we have to all agree, that's no excuse for really easily fixed sloppiness or laziness or bad cryptography (XOR'ing directly to the output), and certainly Linus's behavior was inexcusable, belligerently and unapologetically accusing the petitioners of being clueless and ignorant when in fact they were right and Linus was wrong.  You mentioned below, that in the latest git, they're only using the RDRAND as initialization vector for sha1.  I haven't seen that myself, but if so, it would be one perfectly acceptable, strong and very low cost way to actually solve the problem.  So I hope so.


> As for Matt Mackall quitting...in a zeal to accurate entropy accounting,
> wasn't he busily turning off every entropy source he couldn't
> characterize? (In other words, nearly all entropy sources?) That seemed
> like a really stupid thing--and quite a different approach from your
> more-is-better tinhatrandom design.

I don't actually know about that.  I can say that overestimating the entropy in the pool can lead to security breach, while disabling entropy in the pool can only lead to bad performance.  I can say that I would support slow but good security over fast broken security.

The problem with bad entropy sources would be overestimating their entropy.  But more entropy is better entropy.  So yes, I can totally respect disabling uncharacterizable entropy sources, but if I were there to talk about it at the time, I would have encouraged not disabling the entropy source, but instead disabling or discounting its contribution to the entropy count estimator.

I recently analyzed the BouncyCastle Csharp SecureRandom() class, and found that it was atrociously insufficient in the entropy department.  It had some really severely broken details.  The most egregious offense was the exclusive use of ThreadedSeedGenerator class, which produced output that sometimes lzma compressed to approx 11% of its original size.  That's bad.  Really, really bad.

I submitted patches to fix SecureRandom by utilizing the system RNG as an entropy source, and increasing seed sizes to appropriate levels, but there is no known solution in sight for ThreadedSeedGenerator.  I still allow ThreadedSeedGenerator to contribute to tinhatrandom, but it's discounted 8x.


> I was startled when I happened upon this in the code and I cold e-mailed
> him about it. He was pissed as hell that I would dare e-mail him and he
> was doing me a great favor to answer my e-mail to tell me he was pissed
> that I e-mailed him. 

I don't know about your interaction with him - but I know my interaction with him has been positive.  And I know my reaction to Linus's "colorful" interjections upon the world have been negative, in the random.c situation and a few others.  He really needlessly acts like a dick a lot of the time.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org