Cryptography rarely fails because an algorithm is broken. It fails in the details around it: a nonce that repeats, a random generator seeded with the time, a signature that is verified but not bound to its context, a key that is derived correctly and then written to a log.
These failures are silent. The system works, the tests pass, and a private key can be recovered from the signatures it has already published. We review the design for what it assumes and the implementation for whether the assumptions hold, and we test the output where mathematics allows a verdict: signatures, random values and ciphertexts.
Signature schemes: ECDSA and EdDSA nonce generation, malleability, replay
Key generation, derivation, storage, rotation and destruction
Random number generation and entropy sources
Encryption modes, padding, authentication of ciphertext
Wallets and custody: seed handling, derivation paths, signing flows
Threshold and multi-party schemes, multi-signature configurations
Integration with hardware security modules and key management services
Side channels in software: timing, error behaviour, memory handling
02Approach
How the work is done
01
Design review
We read the specification and state the security properties the design claims and the assumptions it depends on.
02
Implementation review
The code is compared with the design. We look at how libraries are used and where the implementation departs from what the design requires.
03
Analysis of outputs
Signatures, nonces and random values produced by the system are analysed for bias, reuse and structure, using lattice and statistical methods.
04
Attack demonstration
Where a weakness is exploitable, we demonstrate it on test keys generated for the purpose. Keys that protect real assets are never the target of a demonstration.
We use a well-known library. Is there anything to review?
Yes. The library is rarely the problem. The way it is called, the parameters it receives and what happens to keys before and after the call are where the errors are.
Will you work with our production keys?
No. We work with test keys and with public outputs such as signatures. If the analysis of public data shows that a production key is at risk, you are informed at once and the key is not reconstructed.
Can you review a protocol that exists only on paper?
Yes, and it is the cheapest moment to do it. A design flaw found before implementation costs a document change.