On Sat, Aug 8, 2020 at 3:28 PM George Spelvin <l...@sdf.org> wrote:
>
> It's not a theoretical hole, it's a very real one. Other than the cycles
> to do the brute-force part, it's not even all that complicated. The
> theory part is that it's impossible to patch.
We'll just disagree.
I'm really fed up with security holes that are brought on by crypto
people not being willing to just do reasonable things.
> *If* you do the stupid thing. WHICH YOU COULD JUST STOP DOING.
We're not feeding all the same bits to the /dev/random that we're
using to also update the pseudo-random state, so I think you're
overreacting. Think of it as "/dev/random gets a few bits, and prandom
gets a few other bits".
The fact that there is overlap between the bits is immaterial, when
other parts are disjoint. Fractonal bits of entropy and all that.
> The explain it to me. What is that actual *problem*? Nobody's described
> one, so I've been guessing. What is this *monumentally stupid* abuse of
> /dev/random allegedly fixing?
The problem is that the networking people really want unguessable
random state. There was a remote DNS spoofing poisoning attack because
the UDP ports ended up being guessable.
And that was actually reported to us back in early March.
Almost five months later, nothing had been done, all the discussion
bogged down about "theoretical randomness" rather than to actual
real-life security.
> If you're not an idiot, explain.
>
> Because right now you sound like one. There's a simple and easy fix which
> I've described and will get back to implementing as soon as I've finished
> yelling at you. What, FFS, is your objection to considering it?
By now, I'm not in the least interested in theoretical arguments.
I claim that the simple "mix in (different parts of) the TSC bits and
IP bits into _both_ the pseudo random state and the /dev/random state"
is going to make it hell on earth for anybody to ever find weaknesses
in either. Or if they do, they need to find and then exploit them
really quickly, because practically speaking, a few hundred times a
second you end up with noise that you cannot attack algorithmically
perturbing the state of both.
And I realize that drives you crazy. You _want_ to be able to analyze
the state to prove something about it. And that's absolutely the
opposite of what I want. I want the internal state (both prandom and
/dev/random) to simply not be amenable to analysis - simple because we
intentionally screw it up on interrupts. You can analyze it all you
want, knowing that in a few milliseconds you'll have to start over (at
least partially).
So even if you're the NSA, and it turns out that you have a magical
quantum computer that can break the best hash function crypto people
know about by just seeing a fairly small part stream of random
numbers, you'd better figure that state out quickly, because next
interrupt comes along, and we'll perturb it.
Or, say that you find something like meltdown, and can actually use
some side channel to read out the full state of our internal
/dev/random mixing buffers. ALL of it. No magic NSA quantum computer
required, just a side channel. Your "theoretical" are all complete and
utter shit in that case, if all we do is have the best possible secure
algorithm. Because the state is right there, and our
super-duper-secure algorithm is all open source, and your claims of
"this is unbreakable in theory" is just complet and utter nonsense.
This is why I claim the noise that you can't analyze is so important.
You see it as a weakness, because you see it as a "now I can't prove
certain things". I see it as exactly the opposite.
So to me, your whole "theoretical safety" argument is actually a huge
honking weakness.
Btw, you'll really hate what I did to /dev/random for initializing the
pool last year. Another case of "Christ, crypto people have screwed us
for decades, now I'm going to just fix it" situation.
Go do
git log --author=Torvalds --no-merges drivers/char/random.c
and you'll probably have a heart attack.
Linus
