|
|
Subscribe / Log in / New account

Problems emerge for a unified /dev/*random

Problems emerge for a unified /dev/*random

Posted Mar 31, 2022 23:05 UTC (Thu) by gerdesj (subscriber, #5446)
Parent article: Problems emerge for a unified /dev/*random

I love the idea of random == urandom but the snags all seem to be about the boot process. Does this not indicate that there still a need for (at least) two randoms. Another one could be random_boot or brandom or whatever.

A booting system is obviously not in the same state as it will be when it's fully initialised and running, so why insist on pseudo devices like random being a "one size fits all"?

VPNs and webservers for example are huge consumers of randomness and can happily wait until the system is up and running and firing on all four. They could really benefit from a relatively simple random that "knows" that suitable sources of entropy are available and cryptographic researchers aren't going to get sarcastic! They tend to be bloody complicated and any simplification would be a good thing: eg an assumption about the quality of random.

The things that need early random can use brandom and accept its limitations and work with them and then switch to random when it's available if they need to.

Another option might be to have one random device that describes how useful it thinks it is and leave the consumer to take action based on that. "Hi I'm Mike and here's a stream of gibberish-ish(3)". The road to Hell is paved with odd interfaces ...


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds