Random numbers for Linux should poll `/dev/random` once about cryptography-kotlin HOT 6 CLOSED

It definitely still makes sense to support /dev/urandom fallback in the absence of getrandom support. Never know how your library will be utilized in other projects and for what purpose.

from cryptography-kotlin.

Thought of a scenario where supporting fallback to /dev/urandom would be necessary. If you plan to also support Android Native. Most manufacturers only provide 2 years of updates, and there are a TON of devices running old versions which do not have getrandom available.

from cryptography-kotlin.

Thanks for pointing this!
But, I'm not sure, that link you've posted is what we need to do. The issue in blog post is regarding requiring of initialisation of JCA SecureRandom with values from urandom. We don't have anything like this.
But, I've read more info about random/urandom and from what I've found: urandom provides enough entropy by default for short-living operations and is seeded enough after boot.
So IMO, what is needed, is to leave current approach, but provide additional API to force reseeding random for long-living operations like when generating certificates (which is not availability at the moment)

WDYT?

from cryptography-kotlin.

Imo reseeding is unnecessary. Can see how rust-random has it implemented (polling /dev/random once to ensure /dev/urandom has been seeded).

getrandom does it this way (polling /dev/random once), but requires a syscall and check if it's available.

from cryptography-kotlin.

Im now thinking - may be just drop urandom support at all and use getrandom all the time. It was introduced in linux kernel 3.17 (2014!).
does it really make sense to support fallback?

from cryptography-kotlin.

fixed in 3e6e004 (forgot to link issue in commit...)
Thx for pointing!

from cryptography-kotlin.