Now
MAIN commitmail json YAML
cprng(9): Fix accidental 4x seed size.
With SHA-256, NIST Hash_DRBG takes an preferred 440-bit/55-byte seed.
It's a weird number, and I'm not sure where it comes from (a quick
skim of SP800-90A doesn't turn anything up), but it's certainly
sufficient (256-bit/32-byte seed is almost certainly enough) so it's
not a problem to use something larger; Hash_DRBG can absorb seeds of
arbitrary lengths and larger seeds can't really hurt security (with
minor caveats like HMAC RO quirks that don't apply here).
Except -- owing to a typo, we actually used a 1760-bit/220-byte seed,
because I wrote `uint32_t seed[...]' instead of `uint8_t seed[...]'.
Again: not a problem to use a seed larger than needed. But let's
draw no more than we need out of the entropy pool!
Verified with CTASSERT(sizeof(seed) == 55). (Assertion omitted from
this commit because we might swap out Hash_DRBG for something else
with a different seed size like 32 bytes.)
With SHA-256, NIST Hash_DRBG takes an preferred 440-bit/55-byte seed.
It's a weird number, and I'm not sure where it comes from (a quick
skim of SP800-90A doesn't turn anything up), but it's certainly
sufficient (256-bit/32-byte seed is almost certainly enough) so it's
not a problem to use something larger; Hash_DRBG can absorb seeds of
arbitrary lengths and larger seeds can't really hurt security (with
minor caveats like HMAC RO quirks that don't apply here).
Except -- owing to a typo, we actually used a 1760-bit/220-byte seed,
because I wrote `uint32_t seed[...]' instead of `uint8_t seed[...]'.
Again: not a problem to use a seed larger than needed. But let's
draw no more than we need out of the entropy pool!
Verified with CTASSERT(sizeof(seed) == 55). (Assertion omitted from
this commit because we might swap out Hash_DRBG for something else
with a different seed size like 32 bytes.)