I love this work! but my heart breaks that this DRBG won't see much use in many commercial and government environments. Businesses with Federal government customers are often required to use FIPS validated or at least FIPS compatible implementations, which the Blake / ChaCha20 construction definitely isn't. Businesses don't want to maintain multiple versions, so in practice they just switch to the FIPS mode implementation and that's what actually gets used.
This reflects a schism in the cryptography world; organizations that have to do what NIST says, which is basically AES, SHA2, SHA3, HMAC, and the new PQ suites, each the result of competitions and a lot of academic analysis, and open source cryptographers who prefer Blake, ChaCha20, 25519, and other algorithms that have been developed in the open and with a stronger emphasis on performance.
Even though this work is great and proves some of the DRBG security to the same extent as other DRBGs, I doubt we'll see the DRBG added to the approve NISTs lists ever. Just not how it works.
NIST added Ed25519, Ed448, EdDSA, deterministic ECDSA as in RFC 6979, and deprecated RSA key lengths <2048 bits in FIPS 186-5. So I'd not say it'll never happen. It's just slow.
Ed25519 is not just about performance. It, unlike other elliptic crypto, was explicitly constructed to avoid data-dependent branches and memory access patterns that could be exploited as side channels via timing.
This reflects a schism in the cryptography world; organizations that have to do what NIST says, which is basically AES, SHA2, SHA3, HMAC, and the new PQ suites, each the result of competitions and a lot of academic analysis, and open source cryptographers who prefer Blake, ChaCha20, 25519, and other algorithms that have been developed in the open and with a stronger emphasis on performance.
Even though this work is great and proves some of the DRBG security to the same extent as other DRBGs, I doubt we'll see the DRBG added to the approve NISTs lists ever. Just not how it works.