A C implementation of elliptic-curve-based Direct Anonymous Attestation (DAA) signatures. Created to support the Xaptum Edge Network Fabric, an IoT Network Solution.
Currently, we obtain a random seed from a call to libsodium's randombytes_buf, or allow the user to supply the random seed, then use that to seed a userspace csprng which is then used for all subsequent randomness.
It may be wise to eschew the userspace csprng and just take randomness from some user-specified system source (e.g. getrandom or arc4random or just reading from /dev/urandom).
This is currently a commonly-recommended practice from many crypto experts (eg. DJB on urandom.
Some of the perils of using a userspace csprng include (to my knowledge):
Rather than relying on a second codebase (the implementation of the csprng), which will still rely on proper seeding that came from the system's randomness, just use the system's randomness and rely on all the kernel devs maintaining that properly
Forking can cause problems, if the new process gets the exact same rng memory layout
Libsodium's randombytes_buf handles all that for us, but we just use it for seeding. We could just use randombytes_buf, but we also want to support platforms that may not be supported by libsodium.
So, maybe just be totally agnostic to this decision, and allow the user to specify this (and indicate that the common best answer will be, on recent-enough Linux, to use getrandom). That's putting a lot of power in the hands of the user, but may be the best way forward.
Currently, we obtain a random seed from a call to libsodium's
randombytes_buf, or allow the user to supply the random seed, then use that to seed a userspace csprng which is then used for all subsequent randomness.It may be wise to eschew the userspace csprng and just take randomness from some user-specified system source (e.g.
getrandomorarc4randomor just reading from/dev/urandom).This is currently a commonly-recommended practice from many crypto experts (eg. DJB on urandom.
Some of the perils of using a userspace csprng include (to my knowledge):
Libsodium's
randombytes_bufhandles all that for us, but we just use it for seeding. We could just use randombytes_buf, but we also want to support platforms that may not be supported by libsodium.So, maybe just be totally agnostic to this decision, and allow the user to specify this (and indicate that the common best answer will be, on recent-enough Linux, to use
getrandom). That's putting a lot of power in the hands of the user, but may be the best way forward.