3 ms·

Well, there's several Cavium devices that support the deprecated/back-doored Hash_DRBG. For example, these devices were validated for the completely appropria

Well, there's several Cavium devices that support the deprecated/back-doored Hash_DRBG. For example, these devices were validated for the completely appropriately named "SonicOS 6.2.5 for TZ, SM and NSA". Gotta appreciate the irony. Cavium CN7020 Hash DRBG Cavium CN7130 Hash DRBG Cavium Octeon Plus CN66XX Family Hash DRBG Cavium Octeon Plus CN68XX Family Hash DRBG I don't know if that's hardware support or just a software validation - but it's still interesting that they validated it. https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/details?validation=3445 https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Valid...

dfox 3y ago
Except Hash_DRBG is neither deprecated nor backdoored. See NIST SP 800-90A Rev. 1 section 10.1.1.1 for description of the algorithm.
- convivialdingo 3y ago
  Well, true.. the Hash_DRBG hashing algorithm remains. But it's rather likely that previous FIPS validations occurred utilizing the actual backdoored and deprecated algorithm as an input to the Hash_DRBG, rendering it's security properties suspect. In NIST SP 800-90A Rev. 1, the HASH_DRBG section has been significantly updated to that effect. For instance, Appendix E: (Informative) Revisions. Section 10: Section 10 now includes a link to the DRBG test vectors on the NIST website. Sections 10.1, 10.1.1 and 10.1.2 now include short discussions about selecting hash functions to support the DRBG's intended security strength. The Dual_EC_DRBG has been removed, and section numbers adjusted accordingly.
  - dfox 3y ago
    The backdoor in DualEC_DRBG only works if there is some way for the attacker to directly observe its outputs (eg. using that for IVs). If you use it as an inner CSPRNG that seeds other faster algorithms the backdoor is irrelevant, but well, such a construction is total nonsense that only ever makes sense in the FIPS certification framework (DualEC_DRBG is ridiculously slow and not meaningfully more secure than the other FIPS CSPRNGs). On the other hand, I have the feeling that if you instantiate Hash_DRBG with certain classes of insecure hash functions (think MD2) the mechanism that protects the construction from effects of birthday paradox makes it simpler to break the underlying hash function, but for this attack to work the underlying hash function have to be really bad and this attack is probably impractical even for instantiations with MD4, much less the SHA variants in the specification.

dfox 3y ago

Except Hash_DRBG is neither deprecated nor backdoored. See NIST SP 800-90A Rev. 1 section 10.1.1.1 for description of the algorithm.

convivialdingo 3y ago
Well, true.. the Hash_DRBG hashing algorithm remains. But it's rather likely that previous FIPS validations occurred utilizing the actual backdoored and deprecated algorithm as an input to the Hash_DRBG, rendering it's security properties suspect. In NIST SP 800-90A Rev. 1, the HASH_DRBG section has been significantly updated to that effect. For instance, Appendix E: (Informative) Revisions. Section 10: Section 10 now includes a link to the DRBG test vectors on the NIST website. Sections 10.1, 10.1.1 and 10.1.2 now include short discussions about selecting hash functions to support the DRBG's intended security strength. The Dual_EC_DRBG has been removed, and section numbers adjusted accordingly.
- dfox 3y ago
  The backdoor in DualEC_DRBG only works if there is some way for the attacker to directly observe its outputs (eg. using that for IVs). If you use it as an inner CSPRNG that seeds other faster algorithms the backdoor is irrelevant, but well, such a construction is total nonsense that only ever makes sense in the FIPS certification framework (DualEC_DRBG is ridiculously slow and not meaningfully more secure than the other FIPS CSPRNGs). On the other hand, I have the feeling that if you instantiate Hash_DRBG with certain classes of insecure hash functions (think MD2) the mechanism that protects the construction from effects of birthday paradox makes it simpler to break the underlying hash function, but for this attack to work the underlying hash function have to be really bad and this attack is probably impractical even for instantiations with MD4, much less the SHA variants in the specification.