Install Chain Insights
← All stories

Safety Academy · Story 18 · Broken signing libraries

Signature valid. Secret at risk.

The demo signs successfully. That is only the first question.

Estimated 4 min read

BROKEN SIGNING LIBRARIES6 scenes

The team’s signing shortcut passes a demo.

Ken tests a modified ECDSA signer, a digital-signature method used by wallets. Its first signature verifies. The team has proved one operation works, not that their modification protects the key.

Ken
“The signature verifies. We are done?”
Illustration: The team’s signing shortcut passes a demo.

A valid signature alone does not establish that the private key stays protected.

The shortcut reuses a secret signing value.

The shortcut reuses one secret per-signature value across different messages with the same key. This value is called a nonce; it is not the transaction counter displayed by a wallet.

Capitano Ritas
“The optimisation removed the wrong work.”
Illustration: The shortcut reuses a secret signing value.

This per-signature value is called a nonce. It is not the transaction counter shown by a wallet.

A review catches reuse across different messages.

A review detects the repeated value even though both signatures verify. Release stops. In ECDSA, this reuse can expose the private key.

Ken
“Both signatures work. That is the worrying part.”
Illustration: A review catches reuse across different messages.

In ECDSA, reusing that value across different messages can expose the private key.

Capitano Ritas removes the home-made shortcut.

Capitano Ritas removes the custom shortcut and returns to a maintained, reviewed implementation. Proper deterministic signing can be safe; the error here is incorrect reuse across different messages.

Capitano Ritas
“Valid signatures, repeated secret. An impressive way to fail the wrong test.”
Illustration: Capitano Ritas removes the home-made shortcut.

Well-designed deterministic signing can be safe. The problem here is incorrect reuse, not determinism itself.

The team validates the replacement before release.

The replacement goes through configuration review and known test vectors before release. If an old key had already been exposed, fixing the signer would not make that key secret again.

Ken
“We are not patching cryptography by vibes.”
Illustration: The team validates the replacement before release.

Fixing the library would not make a previously exposed private key secret again.

The flawed signer stays out of production.

The faulty signer stays out of production. Specialist review matters when changing signing internals. Cancelling this release turns out to be the team’s most effective optimization.

Ken
“The useful optimisation was cancelling this release.”
Illustration: The flawed signer stays out of production.

Do not modify signing internals without specialist review.

The useful bit

Successful signatures can still come from a dangerously flawed implementation.

  1. Sign with a maintained, reviewed library. No homemade shortcuts.
  2. Check the configuration against known test vectors. A signature that verifies is not proof of safety.
  3. Experiment with throwaway keys only. Watch the library's security advisories.

I already did this

If the flawed signer used real keys, stop signing and treat affected keys as potentially compromised. Get specialist incident help to replace keys and protect remaining assets in a new wallet. Fixing the signer cannot restore secrecy to an exposed key.

Sources & further reading