hackinet commited on
Commit
30219a6
·
verified ·
1 Parent(s): 6b93c3b

Correct theoretical-foundations section: distinguish multiplicative-group DL bit-hardness (Hastad-Naslund, J.ACM ~2004) from ECDLP, which inherits the result by analogy but is not literally that paper.

Browse files
Files changed (1) hide show
  1. README.md +16 -3
README.md CHANGED
@@ -14,7 +14,7 @@ pipeline_tag: tabular-classification
14
 
15
  # secp256k1 Parity Prediction — Negative-Result Study
16
 
17
- **TL;DR — This is a negative-result artifact.** Five model families were trained to predict the parity of the secp256k1 private key `k` from features of the public-key point `(X, Y)`. All converged to **exactly 50% accuracy** on held-out k's, consistent with the well-known parity-bit hardness theorem (recovering one bit of the discrete log is as hard as recovering the whole key).
18
 
19
  > Do **not** use these models for any cryptographic application. They cannot predict the parity of `k`, by construction.
20
 
@@ -22,7 +22,20 @@ pipeline_tag: tabular-classification
22
 
23
  Given a secp256k1 public-key point `Q = k·G = (X, Y)`, predict `k mod 2` (whether the underlying private scalar is odd or even).
24
 
25
- This is the "least-significant bit" of the discrete logarithm. Håstad & Näslund (2004) proved that recovering any single bit of `k` from `Q` is computationally equivalent to solving the full discrete logarithm — so we expect every model to land at 50% accuracy (coin flip).
 
 
 
 
 
 
 
 
 
 
 
 
 
26
 
27
  ## Data
28
 
@@ -136,7 +149,7 @@ bx.load_state_dict(torch.load("models/bit_xformer.pt"))
136
 
137
  ## Out-of-scope use
138
 
139
- - Any actual cryptographic key-recovery attempt. These models cannot do it; the underlying theorem says no model can.
140
  - Any conclusion about non-curve-based ciphers or curves other than secp256k1.
141
 
142
  ## Hardware & cost
 
14
 
15
  # secp256k1 Parity Prediction — Negative-Result Study
16
 
17
+ **TL;DR — This is a negative-result artifact.** Five model families were trained to predict the parity of the secp256k1 private key `k` from features of the public-key point `(X, Y)`. All converged to **exactly 50% accuracy** on held-out k's, consistent with the long-held cryptographic belief that even one bit of the discrete logarithm is as hard to recover as the whole key.
18
 
19
  > Do **not** use these models for any cryptographic application. They cannot predict the parity of `k`, by construction.
20
 
 
22
 
23
  Given a secp256k1 public-key point `Q = k·G = (X, Y)`, predict `k mod 2` (whether the underlying private scalar is odd or even).
24
 
25
+ This is the "least-significant bit" of the discrete logarithm.
26
+
27
+ ## Theoretical context (carefully stated)
28
+
29
+ There is a body of work showing that individual bits of the discrete logarithm are "hardcore" — that predicting any single bit with non-negligible advantage implies efficiently solving the full discrete log:
30
+
31
+ - **Blum & Micali (1984)** — introduced the framework of hardcore predicates and proved the MSB ("which half") of DL in Z*_p is hardcore.
32
+ - **Long & Wigderson (1988)** — extended this to O(log log p) bits.
33
+ - **Boneh & Venkatesan (1996)** — hardness of the most significant bits of Diffie–Hellman shared secrets.
34
+ - **Håstad & Näslund (≈2004, J. ACM)** — *"The Security of all RSA and Discrete Log Bits"*. Proved every individual bit of the discrete log in Z*_p (and of the RSA function) is hardcore.
35
+
36
+ These foundational results are for the **multiplicative group** Z*_p (and RSA), **not literally for elliptic curves**. The analogous statement is widely *accepted* and *expected* to hold for ECDLP on curves like secp256k1, and follows from the same proof techniques applied to the ECDLP setting, but a single canonical "ECDLP bit hardness" reference of the same standing as Håstad–Näslund is harder to point to cleanly. In practice this is the universally held view in the cryptographic community.
37
+
38
+ The empirical result here is consistent with that belief: no architecture we tried beats 50%.
39
 
40
  ## Data
41
 
 
149
 
150
  ## Out-of-scope use
151
 
152
+ - Any actual cryptographic key-recovery attempt. These models cannot do it; the underlying theory says no efficient model can.
153
  - Any conclusion about non-curve-based ciphers or curves other than secp256k1.
154
 
155
  ## Hardware & cost