Vincent Lefevre wrote in
<20200421205425.gb838...@zira.vinc17.org>:
|On 2020-04-20 19:57:23 +0200, Gero Treuner wrote:
...
|> If we don't want to be deterministic, then I don't see a major advantage
|> of hash functions compared to random data.
|
|In this case you need to make sure that such random data cannot be
|guessed. This may be difficult without using entropy. Using entropy
|each time Mutt is started would not be a good idea, in case a system
|would run Mutt several times a second to send mail (e.g. personalized
|mail to its users).
Ah, what a total mess that topic is (random stuff that is)!
Regarding this, the MUA i maintain does
snprintf(rv, i, "%04d%02d%02d%02d%02d%02d.%s%c%s",
tmp->tm_year + 1900, tmp->tm_mon + 1, tmp->tm_mday,
tmp->tm_hour, tmp->tm_min, tmp->tm_sec,
mx_random_create_cp(rl, &reprocnt), sep, h);
where "rl" is either 5 or 8, dependent on whether we include
a "from" address in the ID or only a hostname. random_create_cp()
returns a Base64URL encoded random number string. So far so good.
We have several random possibilities, the fallback is the old
well-known ARC4 digest on home-brewed seed (with time slice
release, gettimeofday / clock_gettime), but we can also seed via
getrandom (sys/libc), /dev/urandom, or entirely leave all the
random stuff up to arc4random or OpenSSL. Older versions of the
latter were driven to save ~/.rnd, which should improve random
security when used more often, possibly, maybe, i would think.
Newer ones of the latter are now driven to not auto-seed
internally, which could cause random queries to fail (!!), i do
not know what they thought when they changed this. (I would have
made the failure optional at best. Funny that Linux now stops
taking care at all.)
Uff.
Ciao from Germany,
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
