Install Chain Insights
← All stories

Safety Academy · Story 17 · Weak key generation

Looks random. Isn’t enough.

Penny’s demo produces impressive-looking keys from the wrong source.

Estimated 4 min read

WEAK KEY GENERATION6 scenes

The demo generates a fresh-looking key.

Penny tests a wallet prototype using disposable keys and no real funds. Every key looks different. The demo appears to work, which is not the same as proving the secrets are unpredictable.

Penny
“Different letters every time. Looks random to me.”
Illustration: The demo generates a fresh-looking key.

Appearance is not a test of cryptographic randomness.

The random source was chosen for convenience.

The prototype uses a general-purpose random function because it was convenient. Nobody intended a scam. The mistake is choosing a source that was not designed to protect secret keys.

Captain Harold
“It passed the “looks complicated” audit.”
Illustration: The random source was chosen for convenience.

A strong algorithm cannot rescue keys chosen from a predictable set.

A review finds the unsafe generator.

Review finds Math.random in the key-generation path. Penny pauses release. A long output does not repair a predictable source, even when the letters look impressively complicated.

Penny
“So a long key can still be a small guessing game?”
Illustration: A review finds the unsafe generator.

Never use a general-purpose random function such as Math.random to generate private keys.

Captain Harold checks where the randomness comes from.

Captain Harold checks the maintained wallet library’s documented key-generation method and required platform cryptographic random source. The production environment must satisfy those requirements too.

Captain Harold
“It looks random. So did my first attempt. Let’s check the source.”
Illustration: Captain Harold checks where the randomness comes from.

Correct library use and the environment both matter. Do not invent your own key generator.

The team replaces the unsafe key-generation path.

The team replaces the unsafe path, discards the disposable demo keys and gets independent review before trusting it with funds. Passing functional tests alone cannot prove randomness is secure.

Penny
“The demo keys can retire before they get a salary.”
Illustration: The team replaces the unsafe key-generation path.

Passing tests does not by itself prove randomness is secure.

No real funds rely on the weak demo keys.

No real funds ever depended on these demo keys. If affected keys had shipped, the team would treat them as potentially compromised and migrate under an incident plan. The fix changes the source, not the font.

Penny
“We fixed the source, not the font.”
Illustration: No real funds rely on the weak demo keys.

The habit: verify key generation before trusting it with value.

The useful bit

A key can look random while coming from a predictable generator.

  1. Generate keys with a maintained, reviewed library and the secure random source it requires.
  2. Never use Math.random, and never judge a key by how random it looks.
  3. Keep test keys away from real money. Get a second pair of eyes before release.

I already did this

If real funds used affected keys, treat them as potentially compromised and stop using them. Get specialist incident help to generate new keys through a trusted implementation and move remaining assets. Fixing randomness does not strengthen existing keys; do not add funds to a wallet being automatically drained.

Sources & further reading