Hello Grant, disclaimer: I'm no crypto expert.
Am 15.12.20 um 18:03 schrieb Grant Edwards:
After upgrading a small embedded system's net-snmp from 5.7.3 to 5.8, snmpd now takes a _long_ time to start up. Snmpd used to start "instantly", but now it blocks on /dev/random for as long as 3-5 minutes. This holds up my entire system startup unacceptably.
Newer versions of dropbear also do this, and IIRC and as you said also daemons depending on OpenSSL 1.1 …
Is there any way to avoid this disruptive behavior?
On our embedded devices we start haveged [1] [2] quite early in boot process on systems without hwrng. On systems with very low memory we stop haveged once everything else is started.
This has drawbacks, some crypto experts would not recommend "creating entropy from cpu timing jitter" (there's also jitterentropy-rngd [3] as an alternative to haveged).
On the other hand I think, daemons requiring good random values should actually block until those are available. Especially dropbear lacked this behavior until recently and thus a lot of embedded devices generated weak keys. Choose your trade-off.
I'm not sure if net-snmp needs that kind of good random values at startup? I consider it essential for generating keys.
Greets Alex [1] http://issihosts.com/haveged/ [2] https://github.com/jirka-h/haveged [3] https://github.com/smuellerDD/jitterentropy-rngd _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
