Summary
libcrux-hmac-drbg currently hardcodes the reseed interval as a crate-level const RESEED_INTERVAL: u64 = 1 << 48 and keeps reseed_counter as a private field. There is no way for a consumer to instantiate a DRBG with a shorter reseed interval, nor to inspect/override the counter. Consumers that want a tighter, self-chosen reseed cadence are forced to track their own counter alongside the DRBG and call reseed_from_rng manually.
Motivation
In OpenMLS's libcrux crypto provider we replaced a rand ReseedingRng<ChaCha20Core, OsRng> (which reseeded from the OS every 4 GiB of output) with HmacDrbgSha256. We'd like to preserve an application-defined reseed cadence (e.g. reseed from the OS every N bytes / N generate calls) as defense-in-depth, independent of the DRBG's very large default interval (2^48).
Today this is only achievable by wrapping the DRBG in our own struct that counts bytes and calls reseed_from_rng when a threshold is crossed. That works, but it duplicates state the DRBG already maintains and can't influence the DRBG's own needs_reseed() decision.
Proposed API
Any of the following (in rough order of preference) would solve this:
-
Per-instance configurable interval. A constructor variant that takes the interval, e.g.
pub fn new_with_reseed_interval(
entropy_input: &[u8],
nonce: &[u8],
personalization_string: &[u8],
reseed_interval: u64,
) -> Result<Self, InstantiateError>;and/or a setter pub fn set_reseed_interval(&mut self, interval: u64). needs_reseed() / generate() would then compare against the per-instance value (defaulting to RESEED_INTERVAL).
The same knob would ideally be plumbed through the rand-feature wrappers (HmacDrbgRng / new_from_sys_rng / SeedableRng).
-
Expose the counter. Keep the fixed interval but make the counter settable, e.g. pub fn set_reseed_counter(&mut self, value: u64), so callers can force needs_reseed() to trip earlier.
Notes / constraints
- The configured interval should still be clamped to
<= RESEED_INTERVAL (the NIST SP 800-90A maximum) — the feature is about reseeding more often, never less.
- Please keep
1 << 48 as the default so existing behavior is unchanged.
Summary
libcrux-hmac-drbgcurrently hardcodes the reseed interval as a crate-levelconst RESEED_INTERVAL: u64 = 1 << 48and keepsreseed_counteras a private field. There is no way for a consumer to instantiate a DRBG with a shorter reseed interval, nor to inspect/override the counter. Consumers that want a tighter, self-chosen reseed cadence are forced to track their own counter alongside the DRBG and callreseed_from_rngmanually.Motivation
In OpenMLS's libcrux crypto provider we replaced a
randReseedingRng<ChaCha20Core, OsRng>(which reseeded from the OS every 4 GiB of output) withHmacDrbgSha256. We'd like to preserve an application-defined reseed cadence (e.g. reseed from the OS every N bytes / N generate calls) as defense-in-depth, independent of the DRBG's very large default interval (2^48).Today this is only achievable by wrapping the DRBG in our own struct that counts bytes and calls
reseed_from_rngwhen a threshold is crossed. That works, but it duplicates state the DRBG already maintains and can't influence the DRBG's ownneeds_reseed()decision.Proposed API
Any of the following (in rough order of preference) would solve this:
Per-instance configurable interval. A constructor variant that takes the interval, e.g.
and/or a setter
pub fn set_reseed_interval(&mut self, interval: u64).needs_reseed()/generate()would then compare against the per-instance value (defaulting toRESEED_INTERVAL).The same knob would ideally be plumbed through the
rand-feature wrappers (HmacDrbgRng/new_from_sys_rng/SeedableRng).Expose the counter. Keep the fixed interval but make the counter settable, e.g.
pub fn set_reseed_counter(&mut self, value: u64), so callers can forceneeds_reseed()to trip earlier.Notes / constraints
<= RESEED_INTERVAL(the NIST SP 800-90A maximum) — the feature is about reseeding more often, never less.1 << 48as the default so existing behavior is unchanged.