The Entropy Email
The subject line was "STM32 Entropy Advisory — Action Required," and the most unsettling thing about it, when it landed on my phone in a Nakameguro café last week, was how unremarkable it looked. No exclamation marks. No urgent red fonts. No clumsy grammar. A narrow, clean newsletter layout, the kind Trezor has used for years, with the same header treatment and the same block of legal text at the bottom that nobody ever reads.
It told me that a subset of STM32 microcontrollers used in Trezor devices may have produced insufficient entropy during seed generation, and it asked me to validate that my recovery phrase was created with adequate randomness at a portal linked in the body. There was a reference number. There was a "security bulletin" footer. There was the little padlock.
I have held the same 24 words since 2017. I have never typed them into anything that has a network connection, and I have spent enough of my life reading firmware changelogs to know that the words "entropy" and "STM32" belong together in a Trezor conversation only in the most technical sense. So I closed the tab I had opened out of pure reflex and did what I always do instead: I opened the source.
But here is the thing I could not stop thinking about for the rest of that afternoon. The reason the message worked — because it did work on me, for about four seconds — is that it was not asking me to believe something absurd. It was asking me to believe something that has actually happened before.
In 2013, a flaw in Android's SecureRandom implementation caused a subset of Bitcoin wallets to generate private keys from a catastrophically narrow pool of randomness. Keys collided across users. Funds were swept within hours. A few years earlier, Debian's OpenSSL build shipped with a broken pseudo-random number generator for nearly two years, shrinking the keyspace of everything it touched to something in the neighborhood of thirty-two thousand possibilities. Both events are real. Both are permanent footnotes in the history of cryptography. And both are exactly the kind of history a phishing operator can borrow at zero cost.
The email did not need to be true. It needed to be plausible for the length of one cup of coffee. That is the entire business model, and it is a very good business model right now.
What Trezor Actually Disclosed
Trezor's public response has been, by the standards of security incidents, reasonably clear on the technical facts. The company stated that its devices were not compromised. It said it had worked to take down the phishing domains. And it said it was investigating how attackers managed to obtain access to a legitimate domain — a sentence that deserves far more attention than it has received, because that clause is where the entire story lives.
What sits underneath the advisory is a harder number. This is the third supplier-related security failure touching Trezor's customer base in roughly four weeks.
The first was a breach at ShipMonk, a third-party logistics partner, disclosed in August. Names, phone numbers, home addresses, and the specific contents of customer orders — roughly 80,000 people. The second is the mailing and newsletter infrastructure compromise that produced the email I received. The third is older and less discussed: a support portal intrusion in 2024 that forced the company to warn approximately 66,000 users.
Trezor is not a young protocol experimenting with a token. SatoshiLabs, its parent, has been building in Prague since 2013. It is the oldest name in this category, the one that made "open source firmware" a marketing category rather than a footnote, and the one whose devices have been torn apart by researchers for a decade — Kraken Security Labs ran public audits that became reference reading for anyone evaluating hardware wallets. There is a Bitcoin-only lineage here, a design philosophy built around a single STM32 microcontroller rather than a closed secure element, and a culture that genuinely believes in reproducible builds. If any company in this industry has earned the benefit of the doubt on device security, it is this one.
Which is precisely why the shape of this incident matters. Trezor has not lost a key. Trezor has lost control of the channels through which it speaks to the people who hold the keys.
And it is not alone. BitBox, the Swiss manufacturer with a similarly Bitcoin-first audience, disclosed a breach of its newsletter service provider on a comparable timeline, and by most accounts moved faster and more transparently than Trezor did. SafePal, the Binance-affiliated brand, leaked roughly 40,000 records last month. Three companies, four weeks, one shared failure mode. That is not a coincidence you can file under bad luck.
The Chip That Was Named But Never Broke
Let me be precise about the technical claim, because the precision is the point.
An STM32 is a family of microcontrollers from STMicroelectronics. It is the general-purpose brain of a Trezor device — it runs the firmware, drives the screen, handles USB, and participates in the seed generation process. It is not a secret. It appears in teardown photos and forum threads. It is the kind of component a moderately curious hardware wallet owner has heard of, remembers vaguely, and cannot actually evaluate.
Entropy is the raw randomness from which a seed is derived. A 256-bit seed drawn from a genuinely unpredictable source is beyond brute force by a margin so wide it becomes a philosophical statement rather than a security margin. Debian's broken OpenSSL, by contrast, produced keys from a space of roughly 15 bits. Fifteen bits is not a strong key with a weakness. Fifteen bits is a key you can enumerate before lunch.
So the attacker's claim was structurally sound and factually false, and those two properties had to hold simultaneously for the email to work. It is worth noting what a real entropy failure would look like from the outside. It would not arrive as a newsletter with a support portal. It would arrive as a wave of swept addresses that share statistical fingerprints, discovered by chain analysts before any vendor had time to write a blog post. Entropy failures announce themselves on-chain, not in your inbox.
Here is where the phishing premise gets genuinely clever, and where I want to give credit where it is due. Trezor's firmware has historically collected entropy from more than one source and has long offered users the ability to mix in their own randomness — the practical answer to "what if the hardware generator is compromised" has always been "then add your own dice." The mitigation for the exact vulnerability the attacker described has existed in the product for years. The attacker inverted a known strength into a claimed weakness, betting correctly that almost nobody who receives the email knows what their own firmware does with a true random number generator.
The phishing premise lived precisely in the gap between having heard the word "entropy" and understanding it. A user who knows nothing deletes the email as spam. A user who knows everything checks the header and moves on. The target is the enormous middle: people who read a thread once, who know that STM32 is a real thing, who care enough about their coins to be frightened but not enough to audit a firmware library on a Tuesday afternoon.
Why the Green Padlock Proved Nothing
Now the part that should worry every security team in this industry more than the phishing itself.
Trezor's statement that it is investigating how attackers accessed a legitimate domain is a quiet admission that this was probably not a spoof. Spoofing a display name is trivial. Spoofing a domain is not. Behind every corporate email sits a stack of authentication machinery: SPF, which declares which servers are permitted to send on behalf of a domain; DKIM, which cryptographically signs the message body so a receiver can verify it was not altered; and DMARC, which tells receivers what to do when the first two checks fail. When configured properly, this trio is genuinely effective against the classic impersonation attack.
Read the definitions again, slowly. SPF asks whether a sending server is authorized. DKIM asks whether a message is intact and signed by someone holding the domain's key. DMARC asks what to do when those checks fail. None of them asks whether the message is honest.
Email authentication proves authority, not intent. And authority is exactly what a supply chain attack purchases.
If an attacker holds the sending infrastructure, they hold the signing key. If they hold the signing key, DKIM signs their payload. If DKIM signs their payload, DMARC passes. If DMARC passes, the padlock renders, the brand assets sit in the correct place, and every visual trust signal a user has been trained to look for over the last decade confirms the lie. This is the confused deputy pattern in its purest form: you did not defeat the guard, you gave the guard a uniform and told him the password.
I ran into a version of this problem from the other direction earlier this year. I was designing a workshop series on decentralized identity for around 200 executives at a Japanese bank, and my central analogy was the tea ceremony — specifically, that consent in a self-sovereign identity system is not a signature collected at a counter, but a sequence of small, legible re-affirmations, each one visible to the person making it. The lesson I kept circling in those sessions was that trust is not a credential. Trust is a relationship with a history.
Email authentication, as currently deployed, tries to compress that relationship into a credential. It works right up until the day the credential is stolen. And in a market where a hardware wallet manufacturer outsources its newsletter, its shipping, its support desk, and its analytics to four different vendors, the credential is the most fragile object in the entire chain.
Two Datasets Are Better Than One
What separates this campaign from ordinary phishing is not the email. It is the inventory.
The ShipMonk breach did not leak a mailing list. It leaked names, phone numbers, home addresses, and — critically — the specific products each customer ordered. An attacker who knows that I bought a Model T in a given month and a Safe 3 in another month knows an enormous amount about how I think about custody. Someone who bought one entry-level device and nothing since is a different target than someone who owns three generations of hardware and a Shamir backup. The first is a casual holder. The second is a person with real value at stake and a demonstrated willingness to act when told about a security issue.
The mail infrastructure compromise supplies the delivery channel. The two datasets are separate breaches, from separate vendors, on separate timelines, and they compose into a single weapon. This is the part of the story that a simple list of incidents obscures: the value is not in either dataset alone, but in the join key. An email address is a routing instruction. A home address plus a device model plus an order date is a character profile.
Layered on top of that is the physical channel, and this is where I think the story has been underreported. Customers have already reported receiving scam phone calls and printed letters in the mail referencing their actual orders. A printed letter to a verified home address, carrying Trezor branding, describing a device the recipient demonstrably owns, is a far higher-conversion object than any email, because it exploits a channel where nobody has been trained to look for phishing. There is no padlock on an envelope. People trust paper in a way they no longer trust pixels.
| Attack vector | Target | Cost | Plausible success | |---|---|---|---| | Supply chain data leak + targeted phishing | Seed phrase | Low to moderate | Moderate to high | | Physical side-channel on the device | Private key | Very high | Very low | | Transaction interception or address swapping | Destination address | Moderate | Low | | Social media impersonation of support | Seed phrase | Low | Moderate | | Untargeted mass phishing | Seed phrase | Negligible | Very low |
The row ordering matters more than any individual figure. The cheapest vector against a hardware wallet holder is not the device. It never was.
DeFi taught me to look for the places where human choices are dressed up as natural law — the borrow curve on a major lending market is a governance parameter with an economic philosophy behind it, presented to users as though it were gravity. The same costume change happens here. The marketing story we tell about self-custody is a story about hardware, silicon, and personal discipline. The actual risk surface is procurement.
The Perimeter Nobody Audited
Everyone is asking the wrong question this week, and the wrongness is the story.
The question people are asking is whether Trezor's hardware is still safe. The answer is that it was never the problem. The device is fine. The firmware is open and has been reviewed. The microcontroller was named in a phishing email because it sounds technical, not because it failed.
The question worth asking is why a company whose entire value proposition is a security promise has three separate vendor failures in four weeks, and why the sequence suggests an attack surface that has been quietly expanding for years while the security budget stayed aimed at the silicon.
There is a category error at work in the community's trust model, and it predates this incident by a decade. Auditing source code and auditing a vendor are different disciplines that happen to share a vocabulary. The first is close to mathematics — you read the code, you model the adversary, you find the bug. The second is procurement and governance: reading contracts, demanding incident histories, requiring breach notification clauses, enforcing vendor segmentation so that the newsletter tool cannot exfiltrate the shipping manifest. Open-source firmware does not cover any of it. Yet the community extended the trust earned by the first to the second without ever examining the transfer.
I made this exact mistake at nineteen. In 2017, during the ICO boom, I spent three months reading token distribution contracts line by line, looking for the logic flaw that would betray buyers. I found three critical ones in a storage project's mechanism and wrote them up on a blog nobody read. I felt rigorous. What I had actually done was audit the code while never once asking how the team had sourced its custodian, its auditor, or its payroll provider. I was reading the math and ignoring the humans. The industry is still doing it, just with better-funded adversaries on the other side.
There is a second, softer assumption worth naming. The self-custody narrative has quietly migrated from "not your keys, not your coins" to something closer to "trust the supply chain of a company you have never visited." The user believes their security model is a device sitting in a drawer. The actual model is a graph of vendors — a shipper, a mail provider, a support portal, a KYC vendor, a cloud backup, a payment processor — each one a link, each one a place where the model can fail before the hardware is ever turned on. Nothing in the marketing material acknowledges this. Nothing in the onboarding flow explains it.
And here is the contrarian conclusion I keep arriving at. The most dangerous thing about this incident is not that it happened. It is that the industry has no shared standard for vendor security, and every month without one leaves the same hole open across every brand in the category. BitBox disclosed within roughly an hour of learning about its newsletter breach, which is the correct behavior and should have been the baseline. Trezor's disclosure arrived days later. That gap is not a technology gap. It is an operations gap, and it is entirely fixable.
Even the framing of the risk is misallocated. The chip-level fear that the phishing email exploited is economically irrational: physical side-channel extraction requires laboratory equipment, physical possession, and a target worth the effort, which is why it does not scale. A single attacker with an ESP account and a shipping manifest scales to eighty thousand people before breakfast. Sophistication is not the binding constraint. Cost per unit of trust is.
The uncomfortable corollary is that this may be good news in disguise. Three failures in four weeks, all of them vendor-side, all of them fixable with procurement discipline rather than cryptography, is a diagnosis with a treatment plan. A chip-level break in a decade-old product line would be a much darker story.
What the Chop Is Actually Telling Us
In a sideways market, the temptation is to file a story like this under noise. Hardware wallet manufacturers are not tokens. Nothing about Trezor's balance sheet transmits to a price feed, and BTC is not going to move because a newsletter provider got popped. In the narrow sense, a supply chain breach has no price impact at all.
The narrow sense is the wrong lens. The broader effect is on the ceiling of an entire category's growth curve, and the timing is unflattering. The fourth quarter is when hardware wallet sales historically ramp, when the holiday marketing cycle opens, and when every brand in the category competes on the same promise: that putting your keys on a purpose-built device removes you from the blast radius of exchanges and custodians. Three vendor breaches in four weeks is a direct hit on that promise, delivered just as it is being advertised most loudly.
Where does the demand go? The competitive map is roughly what it has been for a while — Ledger holding the largest share on brand recognition, Trezor behind it with the Bitcoin-maximalist and open-source base, SafePal in the entry-level tier on pricing and exchange integration, BitBox and Coldcard and Foundation occupying smaller, sharper niches defined by country of manufacture, air-gapping, and geek credibility. But the interesting movement is not between brands. It is out of the category.
Every supply chain incident strengthens the case for alternatives that do not require trusting a manufacturing and logistics pipeline at all — multi-party computation wallets that eliminate a single seed phrase entirely, distributed key schemes, and hybrid models where the device is one factor among several rather than the guarantee itself. That migration is slow, and it is real, and it is being accelerated right now by nothing more exotic than a customer list.
The regulatory dimension is quieter but not negligible, and it is where the fallout may actually settle. Trezor is a Czech company selling into the European Union, which means the ShipMonk leak of 80,000 names, phone numbers, and addresses is squarely a GDPR event: notification obligations, potential penalties, and a hard question under Article 28 about whether a controller can demonstrate adequate due diligence over its processors. The Czech data protection authority has a national interest in how this is handled, because Trezor is one of the country's most visible technology companies, and its handling of a personal data breach will be read as a benchmark. Add class action exposure in jurisdictions where plaintiffs need only show an increased risk of harm, and the cost curve of this incident stops looking like a marketing problem.
What I Would Watch For Next
The most dangerous phase of this campaign has not arrived yet, and I want to be explicit about why.
Leaked datasets rarely get used all at once. The economics favor patience. An attacker holding names, home addresses, device models, and purchase dates has an inventory that does not spoil, and the value of that inventory rises if it is deployed after public attention fades — three or six months from now, during a quiet stretch, when a letter arrives in the mail about a recall that nobody remembers being announced. The near-term phishing wave is the noisy, low-yield opening move. The follow-up is the one that works on careful people.
So the practical advice is not novel, but it is worth repeating without decoration: no legitimate hardware wallet manufacturer will ever need your recovery phrase, and any page requesting it is hostile regardless of the padlock, the logo, or the domain. Users who already entered their words should move funds to a newly generated wallet immediately, and should treat the old seed as burned rather than merely exposed. Users who did not enter them should assume their name, address, and device history are now public to someone and act accordingly.
The more important work is at the vendor level. If this industry wants the next decade to belong to self-custody, it needs to publish what it currently keeps vague: third-party risk registers, breach notification timelines, vendor segmentation rules that keep a marketing tool from reaching a shipping database, and a disclosure standard that makes BitBox's one-hour turnaround the floor rather than the outlier. This is not an attack on any company. It is the recognition that hardware wallet firms have become data custodians, and custodians have obligations regardless of what their product does.
The audit is not the end, but the beginning. For fifteen years this industry has inspected its silicon relentlessly, and the silicon has held up. The mailing lists did not. A standard for the unglamorous parts of the stack does not exist yet — but chaos is just creativity waiting for structure, and someone in Prague or Zug or Taipei could write the first draft of it this quarter and make everyone in the category safer by Christmas.
We asked our wallets to show us their code. It is time to ask them who sends their mail. If literacy in the blockchain age is really power, then the next thing we all need to learn is not how entropy works — it is how procurement does.
