Yet more phishing attempts.

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! View quoted note → 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.

I’m gonna be honest, as much as I think bitcoin is important for freedom in the long term, it really doesn’t feel great working in bitcoin this weekend.

LLMs are very two-sided for security. On the one hand, long-latent bugs are finally surfacing. On the other hand, before you choose to use a product, you can get your own code review done for incredibly low cost*! In the short term it’s incredibly bad, in the long-term it democratizes code review greatly. “Don’t trust, verify” finally becomes an actual possibility for normal people! * of course LLMs do still make up issues when asked, push any such review to write PoCs to check their analysis!