< BlueMatt>
gmaxwell: if you think I'm asking too much, feel free to shoot it down....
< BlueMatt>
i have no idea how much work there is there
< gmaxwell>
BlueMatt: no I agree with you.
< gmaxwell>
I don't care if its in this PR however, but it should be in the same release.
< sipa>
gmaxwell: i think it's (fun) overkill
< gmaxwell>
what I'd proposed before is we do the seeder first, feed its output into OpenSSL...
< gmaxwell>
sipa: there have been two OS releases with the OS rng returning nothing useful while we've been working on this project... I don't think making extra effort to not be completely insecure in that case is overkill.
< sipa>
gmaxwell: my assumption is that the (barely maintained) openssl code can't be guaranteeing much in such a broken state either
< sipa>
i agree it's a useful goal to attempt to be secure in that case, but i do see it as a separate improvement
< gmaxwell>
which was why I previously suggested doing it first. :)
< sipa>
this is trivial
< sipa>
librng will be a pain to make production ready
< gmaxwell>
I have no interest in a "librng" I don't think its tractable.
< BlueMatt>
sipa: making it a library yes, making it libgivemeentropy, I'd hope a bit less so
< gmaxwell>
handling concurrency is too hard if you also care a lot about performance.
< sipa>
BlueMatt: wumpus did not feel like pulling all that code into core without making it reusable
< gmaxwell>
I am going to NAK this PR, since it seems unlikely that we'll get improved seeding at all.
< BlueMatt>
(and easier than librng)
< sipa>
gmaxwell: i don't understand
< sipa>
why should improved seeding be a requirement to drop openssl?
< gmaxwell>
You are busy arguing now that we're unlikely to get improved seeding, because wumpus wanted a reusable library, and we've evaluated it and determined that making something fast and fork tolerant while handling concurrency and being portable is more or less too hard.
< gmaxwell>
Because the change is worse than what openssl does!
< sipa>
we don't need the performance requirement anymore
< gmaxwell>
I know we don't, but an external library does if anyone else is ever going to use it. Which is why we haven't done that.
< sipa>
as all needs for randomness are split into high-performance or high-entropy, with no overlap
< sipa>
so a libuserentropy or whatever should become a lot easier to do
< sipa>
which makes it tractable to do
< sipa>
but it's still a lot of work
< sipa>
which i think shouldn't be blocking this
< gmaxwell>
This is obviously weaker than the initilization with openssl. You're basically arguing that this should go first because doing other things won't happen soon. Don't you see why I can't support that?
< gmaxwell>
Seperate PRs fine, but a change that I think is only acceptable with another change that you're saying won't happen soon?
< sipa>
my view is that we currently have no guarantees about security if OS entropy is broken
< sipa>
this makes it stronger, because all randomness queries no go to the OS
< sipa>
*now
< sipa>
if we want security in the assumotion of a broken OS, that is something that can be done independently (and more easily after this PR)
< sipa>
*assumption
< gmaxwell>
It's stronger because it goes straight to something which we've known to be insecure in recent memory?
< sipa>
go find me what openssl would do in those cases
< sipa>
do we even know?
< gmaxwell>
I posted about it before, rng is seeded based on a collection of different pointers and timestamps. And in Bitcoin on windows, based on a screenshot.
< sipa>
does that guarantee anything?
< sipa>
at least you'd need things like memory latency based measurements
< * BlueMatt>
is so confused, what was wrong with taking just the entropy-generating parts, pulling those out into a libgivemeentropy, and using that as an entropy source?
< BlueMatt>
sounds a) doable on a reasonable timeline (unlike, maybe, librng) b) just as good for our usage
< sipa>
BlueMatt: nothing wrong with it, i think it's a great idea
< sipa>
but i think it's orthogonal to chaning the RNG
< BlueMatt>
ok, so lets do both that and removing openssl in the same release and move on with our day?
< sipa>
well if there is a requirement to do it in the same release, we should do it simultaneously
< gmaxwell>
sipa: nothing here guarentees anything; thats a weird ask that you're making.
< sipa>
sigh
< * sipa>
weekend
< sipa>
gmaxwell: if all the seeding code was something we'd just add in random.cpp, i'll gladly do it even in the same PR
< sipa>
but my assumption is that others wouldn't consider that the right place
< sipa>
and if what is needed is a separate library will autotools and various detection for parts of operating systems, that's not something i want to take on writing and maintaing
< sipa>
and if we both need better seeding code and making it effectively reusable are requirements before making progress on our RNG code, then yes, i fear it won't happen
< BlueMatt>
sipa: I'm happy with it in random.cpp, that sounds like a wumpus question, though
< sipa>
yes
< sipa>
but it's not an unreasonable thing to ask
< sipa>
and neither is requiring better seeding code
< sipa>
in my view, if your OS randomness is broken, you're fucked
< sipa>
maybe the current OpenSSL code helps with it, and maybe it doesn't
< sipa>
it's a cool problem, with a cool solution, to try to protect against that
< sipa>
but i don't feel like working on it when there are too many conflicting demands