I've noticed that (besides the Bitcoin test-code) insecure_rand() is only properly (=non-deterministic) seeded when a new transaction is created, which might be after it's already used.
Seeding it here should ensure that current and futures usages don't accidentally start with the default seed.
Seed insecure_rand during start #8903
pull crowning- wants to merge 1 commits into bitcoin:master from crowning-:patch-1 changing 1 files +3 −0-
crowning- commented at 1:18 PM on October 9, 2016: contributor
-
3f6cdac684
Seed insecure_rand during start
I've noticed that (besides the Bitcoin test-code) `insecure_rand()` is only properly (=non-deterministic) seeded when a new transaction is created, which might be _after_ it's already used. Seeding it here should ensure that current and futures usages don't accidentally start with the default seed.
-
JeremyRubin commented at 2:07 PM on October 9, 2016: contributor
This might be out of scope for what you want to do with this PR, but I think if you're trying to fix initialization to guarantee insecure_rand has good entropy it may also be worth trying to fix the race conditions in insecure_rand (there are a few that I've looked at).
-
laanwj commented at 2:37 PM on October 9, 2016: member
Not against this change, but I wouldn't suggest doing too much work for insecure_rand:
- It's called insecure_rand because it shouldn't be used for anything requiring security, it shouldn't matter for its use case if it generates the same sequence every time. If anything does that is a bug.
- One current goal is to replace replace the OpenSSL PRNG with built-in Fortuna implementation - as Fortuna is so fast it will also be used for insecure_rand, see #5885
-
- laanwj closed this on Oct 15, 2016
- crowning- deleted the branch on Nov 9, 2016
- DrahtBot locked this on Sep 8, 2021
