jb_the math break

illustrative sample the math break · 30-day scan

Cryptographic Risk Scan: Example Custody Co.

This is what a client receives at the end of a 30-day scan. The company, systems and findings are fictional, but every finding is a pattern we see in real stacks.

client
Example Custody Co. (fictional)
scope
Hot and warm wallets, signing service, client API, two vendors
period
30 days, remote
prepared by
Joshua Bullock, The Math Break

1 · executive summary

Two things to fix this quarter. Nothing on fire.

The algorithms Example Custody Co. relies on are sound. The risk is in how two of them are used: where the signing service gets its one-time numbers, and how one smart contract checks signatures. Both can be fixed without changing the chain or the custody vendor.

23cryptographic primitives inventoried
4places they live: code, contracts, HSMs, vendors
2fix-now findings
0keys found exposed

2 · risk matrix

Breakability against how hard it is to swap

Each finding is scored 1–5 on two axes. Breakability: how close a practical attack is, counting both the maths and the implementation. Swap difficulty: what it takes to replace, from a library update to an immutable contract.

Top-left is the urgent corner: easy to break, easy to fix. Top-right needs mitigation now and a migration plan.

FIX NOW MITIGATE + PLAN ROUTINE MONITOR swap difficulty → breakability → 01 05 04 02 03 06

3 · findings

Six findings, ranked

F-01Fix now

Signing service’s one-time numbers come from an unaudited source

where
Hot-wallet signing service · ECDSA on secp256k1
what we found
The service uses an older library version that draws each signature’s nonce from the operating system at signing time, rather than deriving it deterministically. Nobody has checked the randomness on the production containers.
evidence
We checked 1.2 million historical signatures for a repeated r value. None found, so no key is exposed today.
why it matters
One repeated or predictable nonce lets anyone compute the private key from public data. See the live demo.
fix
Upgrade to deterministic nonces (RFC 6979) or hedged nonces. Add a repeated-r monitor on outgoing signatures. About one engineer-week.

breakability 4 / 5 · swap 2 / 5

F-05Fix now

Internal tool generates API secrets with a non-cryptographic random function

where
Ops admin tool · client API key issuance
what we found
API secrets for client integrations are generated with a general-purpose random function meant for games and animations, not security.
why it matters
Its output can be predicted from a few samples, so one leaked key can reveal others issued around the same time.
fix
Switch to the platform’s cryptographic generator and rotate keys issued by the tool. About two days.

breakability 4 / 5 · swap 1 / 5

F-04Mitigate

Immutable contract accepts two valid forms of the same signature

where
Withdrawal-approval contract · ecrecover
what we found
The contract calls the raw signature check without rejecting the “high-s” twin that every ECDSA signature has (EIP-2). It also can’t be upgraded.
why it matters
An attacker can submit a second, different-looking copy of an approval. Today that only breaks duplicate detection in the off-chain indexer, but future features may rely on it.
fix
Reject high-s signatures in the relayer and indexer now. Use a vetted signature library in the next contract version.

breakability 4 / 5 · swap 5 / 5

F-02Plan

Custody vendor can’t say how it would replace its algorithms

where
Warm-wallet HSM vendor
what we found
The vendor confirmed the curves it supports but has no published plan or timeline for post-quantum signatures.
fix
Add a crypto-agility clause to the next renewal: a migration roadmap, and notice of algorithm changes.

breakability 3 / 5 · swap 4 / 5

F-03Plan by 2030

Client API relies on RSA-2048 certificates and RS256 tokens

where
Load balancer TLS · API session tokens
what we found
Safe against today’s computers, but on the list NIST’s draft guidance proposes deprecating after 2030 and disallowing after 2035.
fix
Enable hybrid post-quantum key exchange (X25519MLKEM768) at the edge now. Plan ML-DSA tokens once your identity provider supports them.

breakability 2 / 5 · swap 3 / 5

F-06Routine

Service-to-service authentication uses Ed25519

where
Internal mesh
what we found
Well implemented, with keys rotated every 90 days. Quantum-exposed in the long run, but easy to swap.
fix
No action now. Include it in the 2030 migration.

breakability 1 / 5 · swap 1 / 5

4 · roadmap

What to do, in order

  1. next 30 days

    Close the two fix-now findings

    Deterministic nonces and a repeated-r monitor (F-01). Cryptographic generator and key rotation (F-05).

  2. next 90 days

    Contain the contract

    High-s rejection in the relayer and indexer (F-04). Crypto-agility language drafted for the vendor renewal (F-02).

  3. next 12 months

    Start the post-quantum path

    Hybrid key exchange at the edge. A full inventory kept current, owned by one named person (F-03).

  4. by 2030

    Rotate the long-lived primitives

    Post-quantum signatures for API tokens and service auth, timed to vendor support (F-03, F-06).

5 · method and limits

How this was scored

Read-only access to code, contract source, infrastructure configuration and vendor documentation, plus interviews with two engineers. No production keys were handled. Findings are written to the standard of a forensic declaration: what was examined, what was found, and how to reproduce it.

scoring, 1 to 5

Breakability

1: no known practical attack. 3: weakened under realistic conditions, or exposed to quantum. 5: exploitable today.

Swap difficulty

1: a library or configuration change. 3: coordinated releases. 5: immutable, or controlled by a vendor.

get yours

A real report on your stack in 30 days

Founding clients get the scan at case-study pricing in exchange for an anonymized write-up.