Add security/performance disclaimer to README
HEADmaster1 files changed, 10 insertions, 0 deletions
|
diff --git a/README.md b/README.md index 4bff680..b02fb07 100644 --- a/ README.md+++ b/ README.md |
| @@ -4,6 +4,16 @@ Building Schnorr signatures on secp256k1 in Go, from first principles. |
| 4 | |
4 | |
| 5 | **Goal:** Understand the math deeply, not just copy formulas. End with a working (non-production) implementation compatible with Bitcoin Taproot and Nostr. |
5 | **Goal:** Understand the math deeply, not just copy formulas. End with a working (non-production) implementation compatible with Bitcoin Taproot and Nostr. |
| 6 | |
6 | |
| |
7 | > ⚠️ **Not for production use.** |
| |
8 | > |
| |
9 | > This implementation prioritizes clarity over security and performance: |
| |
10 | > |
| |
11 | > - **Not constant-time.** Uses Go's `big.Int`, which has variable-time operations (branches and memory access patterns that depend on secret values). An attacker measuring timing over many signatures could potentially recover private keys. Production libraries use fixed-size arithmetic with no secret-dependent branches. |
| |
12 | > |
| |
13 | > - **~10x slower than btcec.** `big.Int` means heap allocations on every operation, generic modular reduction, and no assembly. Production libraries use stack-allocated fixed-width limbs, exploit secp256k1's special prime for fast reduction, and hand-tuned assembly. |
| |
14 | > |
| |
15 | > For hobby projects on your own hardware? Fine. For anything with real value at stake, use [btcec](https://github.com/btcsuite/btcd/tree/master/btcec) or [dcrd/secp256k1](https://github.com/decred/dcrd/tree/master/dcrec/secp256k1). |
| |
16 | |
| 7 | --- |
17 | --- |
| 8 | |
18 | |
| 9 | ## Progress |
19 | ## Progress |
|