secp256k1

Pure Haskell Schnorr, ECDSA on the elliptic curve secp256k1 (docs.ppad.tech/secp256k1).
git clone git://git.ppad.tech/secp256k1.git
Log | Files | Refs | README | LICENSE

commit 4af78528d96a19bf1508eb245671295936304a02
parent 16dc42c874f7a36f15bd2ee31f3a3a42dff1c8a5
Author: Jared Tobin <jared@jtobin.io>
Date:   Sat, 19 Oct 2024 18:32:51 +0400

meta: tweak readme note

Diffstat:
MREADME.md | 26++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/README.md b/README.md @@ -89,7 +89,7 @@ accurate and safe from attacks targeting e.g. faulty nonce generation or malicious inputs for signature parameters. Timing-sensitive operations, e.g. elliptic curve scalar multiplication, have been explicitly written so as to execute *algorithmically* in time constant with respect to -secret data: +secret data, and evidence from benchmarks supports this: ``` benchmarking derive_public/sk = 2 @@ -129,10 +129,10 @@ secret data: std dev 48.99 μs (40.83 μs .. 62.77 μs) ``` -Integer division modulo the elliptic curve group order, when benchmarked -on its own, does display persistent substantial timing differences on -the order of 2 nanoseconds when the inputs are dramatically different in -size: +Due to the use of arbitrary-precision integers, integer division modulo +the elliptic curve group order does display persistent substantial +timing differences on the order of 2 nanoseconds when the inputs differ +dramatically in size (here 2 bits vs 255 bits): ``` benchmarking remQ (remainder modulo _CURVE_Q)/remQ 2 @@ -148,13 +148,15 @@ size: std dev 882.9 ps (647.8 ps .. 1.317 ns) ``` -This is likely to be within acceptable limits for all but the most -extreme security requirements, but because we don't make "hard" -guarantees of constant-time execution, take reasonable security -precautions as appropriate. You shouldn't deploy the implementations -within in any situation where they could easily be used as an oracle to -construct a [timing attack][timea], and you shouldn't give sophisticated -malicious actors [access to your computer][flurl]. +This represents the worst-case scenario (real-world private keys will +never differ so extraordinarily) and is likely to be well within +acceptable limits for all but the most extreme security requirements. +But because we don't make "hard" guarantees of constant-time execution, +take reasonable security precautions as appropriate. You shouldn't +deploy the implementations within in any situation where they could +easily be used as an oracle to construct a [timing attack][timea], +and you shouldn't give sophisticated malicious actors [access to your +computer][flurl]. If you discover any vulnerabilities, please disclose them via security@ppad.tech.