matt on Nostr: It’s still early, but it’s not at all the case that we cant learn anything from ...

It’s still early, but it’s not at all the case that we cant learn anything from this and do better. If I were a hardware wallet manufacturer, I think my takeaways/changes I’d make are:

1) insecure fallbacks or hashing in weak entropy should be explicitly verboten. Unless it’s 96 bits or higher, do not include it!

2) Anything generating keys on an embedded device should have at least two random inputs and should check them with even basic randomness tests. This requires pulling lots of extra bits in before they’ve been whitened which isn’t possible on all hardware, but hardware that does whitening usually will do tests for you so make sure you’re checking it!

quoting nevent1q…9vun

That’s definitely not true. If you can run a test on the bits (and can extract a few orders of magnitude more bits than you need) before you use them and before they’re hashed/whitened/etc, you can absolutely test for quality. You then take a few sources that you’ve tested and xor/hash it all together and you’d be fairly confident in your robustness.

Sadly, many HW RNGs do whiten the output before you get it so it may not work everywhere, but some HWRNGs do test their data before they provide it!

3. (Obviously) Everyone should be doing regular LLM reviews of software and firmware.

4. HWWs should have an explicit QA step where each input to the RNG is logged and the result of adding those inputs together to build a seed is done on a separate device with a reimplementation and compared against the device's seed. This should be done for each firmware release.

I doubt almost any HWWs today do 2&4.