Expand description
Deterministic random bit generators (NIST SP 800-90A Rev.1): Hash_DRBG, HMAC_DRBG, CTR_DRBG. Deterministic Random Bit Generators (NIST SP 800-90A Rev.1).
The three approved DRBG mechanisms of SP 800-90A §10:
| Mechanism | Section | Backend | Type |
|---|---|---|---|
| Hash_DRBG | §10.1.1 | SHA-2 ([tessera::Digest]) | crate::drbg::hash::HashDrbg<H> |
| HMAC_DRBG | §10.1.2 | HMAC-SHA-2 | crate::drbg::hmac::HmacDrbg<H> |
| CTR_DRBG | §10.2.1 | AES-128/192/256 | crate::drbg::ctr::CtrDrbg |
§Deterministic by design
These generators are deterministic functions of the caller-supplied
entropy input — they never pull OS entropy themselves. This matches
arcana’s “caller-provided randomness” posture (cf. ECDSA / RSA blinding)
and is exactly how the NIST CAVP DRBGVS vectors drive the constructions:
the harness feeds EntropyInput, Nonce, PersonalizationString,
optional AdditionalInput, and (for reseed / prediction resistance)
EntropyInputReseed / EntropyInputPR, and checks the returned bits.
The caller is responsible for supplying entropy from a source with the
required min-entropy (SP 800-90A §8.6.3): at least security_strength
bits in the instantiate/reseed entropy input, and a nonce of at least
security_strength/2 bits (§8.6.7). arcana does not validate the
quality of the entropy, only its length against the seedlen /
security-strength tables of §10.
§Side-channel posture
Per arcana/doc/sca/countermeasures/drbg.rst (planned):
| Concern | Status | Note |
|---|---|---|
Internal state (V, C, Key) is secret | handled | never branched on; all state transforms are data-oblivious |
| Hash_DRBG / HMAC_DRBG on SHA-2 | inherited | data-oblivious SHA-2 / HMAC (no secret-dependent branch/index) |
| Hash_DRBG mod-2^seedlen addition | handled | branch-free byte adder (crate::drbg::util::ct_add_into) |
| CTR increment / counter arithmetic | handled | branch-free (crate::drbg::util::ct_increment) |
| CTR_DRBG AES core | T1-A gap | table-based AES leaks S-box index on shared-L1 CPUs (see below) |
| HMAC-SHA-2 carry-based DPA (Belenky 2023/3) | T2-D gap | the underlying HMAC leak; DRBG key is DPA-extractable |
§CTR_DRBG AES leak — pre-existing T1-A gap, NOT introduced here
crate::drbg::ctr::CtrDrbg calls the existing crate::cipher::aes core, which
is table-based (S-box + T-tables). On CPUs with a shared L1 data cache
this leaks the S-box access pattern, i.e. the DRBG Key. This is the
documented T1-A roadmap item (fixsliced AES, Adomnicai-Peyrin TCHES
2021/1); the DRBG inherits it and does not fix or worsen it. All DRBG
own arithmetic (df, counter increment, XORs) is branch-free and
index-oblivious, so the only residual leak on the CTR path is the
shared AES core. [CESTI: CTR_DRBG inherits the AES T1-A cache leak — point to the fixsliced-AES roadmap item.]
The Hash_DRBG / HMAC_DRBG paths inherit only the (branch-free) SHA-2
compression and, for HMAC, the carry-based DPA of T2-D; they carry no
table lookup on secret data.
Modules§
- ctr
- CTR_DRBG — SP 800-90A Rev.1 §10.2.1, over AES-128 / 192 / 256.
- hash
- Hash_DRBG — SP 800-90A Rev.1 §10.1.1.
- hmac
- HMAC_DRBG — SP 800-90A Rev.1 §10.1.2.
- util
- Shared, data-oblivious arithmetic for the SP 800-90A DRBGs.
Enums§
- Error
- Errors returned by the DRBG mechanisms (SP 800-90A §9).