In this article, as a cryptanalysis of Bitcoin, we will analyze a computational scientific experiment that reproduces and extends the observation of John Zweng (2025) regarding the generator points Gof the Koblitz curve family SEC 2 — secp160k1, secp192k1, secp224k1 и secp256k1.
A discovered pattern: for all Kobitz curves of prime order in the family, SEC 2 (secp160k1, secp192k1, secp224k1, secp256k1)the point obtained by “dividing” the generator G by 2(multiplying by the inverse of 2 modulo the order of the subgroup n) has xan -coordinate of anomalously small bit length and contains a common 152-bit hexadecimal substring 8ce563f89a0ed9414f5aa28ad0d96d6795f9c6. We provide a mathematical formalization of the operation, reproduce the calculations using open-source Python/SageMath scripts, discuss the historical opacity of the standard SEC 2, and—in separate sections—protocol implications for Bitcoin, including the principles of NUMS points, auditing secondary generators, and security ECDSA/Schnorr. Particular attention is given to practical scripts for Google Colab, which allow each researcher to independently verify the finding.
Johannes Zweng, known on GitHub, directly references a talk by cryptographer Nadia Heninger in his archive , addressing the open questions of the origins of standard curves, as additional context for this anomaly. Heninger is a leading expert in the practical cryptanalysis of ECC/RSA implementations (notably, her work on attacks against weak randomness in key generation), and her focus on the topic underscores the significance of such archival findings for the academic cryptography community.
A video of cryptographer Nadia Heninger, co-authored by Travis Scholl and Dan Shumow , discussing the 152-bit hexadecimal substring
8ce563f89a0ed9414f5aa28ad0d96d6795f9c6was presented at the Rump Session at the Crypto 2019 conference.
This refers to a strange structure discovered in the ECDSA algorithm during an analysis of the Bitcoin blockchain. They were looking for collisions nonce(of random nonces) and discovered the following:
- About 99% of the repeated nonce values in the blockchain (which allow the private key to be calculated ) are equal to the value, Where— the order of the elliptic curve.
- If we multiply this value by the base point (generator) of the curve, we get
Xa -coordinate that is only 166 bits long, while the standard length for the Bitcoin curve is 256 bits. - When analyzing the entire family of Koblitz curves (secp) from Certicom, it turned out that the generator points in all of these curves have a common constant (the same substring
8ce563f89a0ed9414f5aa28ad0d96d6795f9c6), which differs only in a few high and low bits.
This structure appears to be an undocumented artifact of the process of generating the base points for these curves. Researchers found no evidence that this is a mathematical backdoor (it does not help solve the discrete logarithm problem), but it does shed light on how Certicom selected its curve generators in 1999, which is not officially documented.
Elliptic curve public-key cryptography (ECC) requires six domain parameters: the 𝔽 p field , the curve coefficients a and b , the subgroup order n , the cofactor h , and the generator point G = (G x , G y ) . The SEC 2 standard (Standards for Efficient Cryptography Group, Certicom) specifies these parameters for the secpXXXk1 family of Kobitz curves , of which secp256k1 underlies Bitcoin, Ethereum, and many other blockchain protocols.
The key methodological issue raised by John Zweng is that the procedure for constructing point G in the SEC 2 specification is undocumented . Unlike “verifiably random” curves of class “r1” (secp256r1 and others), for which there is a public seed and SHA-1 algorithm to verify the absence of “backdoors,” there is no such procedure for Koblitz curves. This creates a zone of epistemic uncertainty , particularly important for Bitcoin, where the security of hundreds of billions of dollars’ worth of assets relies on these constants.
It is shown that the point H = G 2⁻¹ (mod n), which “cancels” the doubling operation, has an x-coordinate significantly shorter than the curve’s nominal bit length for all four curves and contains a common 152-bit hexadecimal substring 8ce563f89a0ed9414f5aa28ad0d96d6795f9c6. The code of the analyzed Google Colab notebook is analyzed section by section, providing a mathematical interpretation, a statistical assessment of the probability of a random coincidence, and historical cryptanalytic context—from the DES S-box scandal to Dual_EC_DRBG and the nothing-up-my-sleeve (NUMS) principles.
Practical Verification: Scripts for Google Colab (Python + SageMath)
To independently reproduce John Zweng’s results, we offer two scripts that can be run in the Google Colab environment. The first is in pure Python with a library ecdsa (available in Colab without installation), and the second uses SageMath (requires installation, but provides more direct access to elliptic curve functions).
Script (Python + ecdsa library). This script calculates the H- point for secp256k1 and outputs its x -coordinate in hex, and also checks for the presence of a common substring.
# Install the ecdsa library (if not already installed)
!pip install ecdsa
from ecdsa import SECP256k1
from ecdsa.numbertheory import inverse_mod
# secp256k1 parameters
curve = SECP256k1.curve
G = SECP256k1.generator
n = SECP256k1.order
# Find the inverse of 2 modulo n
inv2 = inverse_mod(2, n)
# Calculate H = G * inv2
H = G * inv2
# Get the x-coordinate in hexadecimal (without the 0x prefix)
x_hex = hex(Hx())[2:]
print("x(H) = 0x" + x_hex)
print("Bit length of x(H):", len(x_hex) * 4, "bits")
# General substring (152 bits = 38 hex characters)
common = "8ce563f89a0ed9414f5aa28ad0d96d6795f9c6"
if common in x_hex:
print("✅ Common 152-bit substring DETECTED!")
else:
print("❌ Substring not found.")
# Extra: check that 2*H == G
twoH = H * 2
assert twoH == G, "Error: 2*H != G"
print("✓ Check: 2*H == G passed.")
Execution result (for secp256k1): x(H) = 0x3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63, substring found, bit length ~166 bits.
Practical application in Bitcoin auditing. The proposed methodology (dividing the point by 2 and analyzing the bit length) can be integrated into tools for verifying new protocol constants. For example, when introducing secondary generators for confidential transactions, Pedersen commitments, or aggregated signatures (MuSig2, FROST), it is recommended to perform the “John Zweng test”—dividing by small numbers (2, 3, 5, 7) and checking for abnormally short coordinates, which is a heuristic indicator of an opaque or potentially compromised design.
The secp256k1 Anomaly: The Hidden Structure of Koblitz Curves
The secp160k1, secp192k1, secp224k1, and secp256k1 curves belong to the Koblitz curve family standardized in Certicom’s SEC 2: Recommended Elliptic Curve Domain Parameters document. The secp256k1 curve has gained particular significance due to its use in Bitcoin, Ethereum, and dozens of other cryptocurrency protocols, where the generator G defines the entire ECDSA public key space .
Screencast: https://youtu.be/44CG3WhovE8
Google Colab: https://colab.research.google.com/drive/1e42DLAfRqEwTmsTNwZW2DFNC21umz6d0?usp=sharing
The Google Colab notebook under review aims to test a conjecture first published by John Zweng in 2025 as a SageMath script: if a generator G is multiplied by the multiplicative inverse of 2 modulo the group order n, then the resulting point H = G 2⁻¹ has an anomalously short and structurally repeating x-coordinate.
A historical parallel. Such “hidden regularities” in cryptographic constants are nothing new. In 1975, during the standardization of DES, the cryptographic community accused the NSA of introducing “opaque” S-boxes; only 15 years later, after the discovery of differential cryptanalysis by Biham and Shamir, was it revealed that DES’s S-boxes had been specifically strengthened against this as-yet-unpublicized attack. The secpXXXk1 anomaly is an example of the same phenomenon in reverse: a structure that appears suspicious but has not yet been proven to be vulnerable.
The Shadow of Dual_EC_DRBG and the Mystery of the X-Coordinate in Cryptanalysis
The first cell in Google Colab formulates a “key discovery”: for all four curves, the point H = G 2⁻¹ has an x-coordinate that is significantly shorter than the nominal curve size and contains a common 152-bit substring. In our research, we were forced not to acknowledge the existence of a “backdoor,” but to raise the question of the transparency of the parameter generation process used, among other things, by Bitcoin.
This formulation is consistent with the nothing-up-my-sleeve (NUMS) principle —the requirement that cryptographic constants be derived in a deterministic and verifiable manner that prevents the hidden selection of values that are “convenient” for an attacker.
An example from the cryptanalysis archives. The most famous historical case of a violation of the NUMS principle is the Dual_EC_DRBG pseudorandom number generator , standardized by NIST in SP 800-90A. The constants P and Q, defining the generator’s elliptic curve, were proposed by the NSA without explanation of their origin.
Installing libraries ( fastecdsa pandas)
!pip install fastecdsa pandasThe first code cell in Google Colab installs a library fastecdsathat provides primitives for elliptic curve arithmetic and pandas for tabular presentation of results. The output reports a package version conflict ( pandas 3.0.3 versus the one required by Colab pandas<2.2.2)—a dependency issue typical for Colab environments that doesn’t affect the mathematical results but requires attention when reproducing the experiment.
Diagnosing a Curve Import Failure in the Enigma Cipher
The second markdown cell in Google Colab describes the diagnosed problem: direct import of objects secp160k1, secp192k1, secp224k1, secp256k1 from fastecdsa.curve is unstable between
The solution is to explicitly construct curve objects from the published SEC 2 domain parameters (p, a, b, order q, generator coordinates gx, gy), which makes the calculation independent of the internal structure of a particular library version.
A historical parallel. The cryptographic code’s dependence on “magic” library constants is reminiscent of the Enigma cipher : the capture of German switching tables and rotor settings (for example, during the Polish Biuro Szyfrów and later Bletchley Park operations) allowed the Allies to reconstruct “system parameters” directly, rather than relying on assumptions about its internal structure—methodologically, this is the same as explicitly specifying domain parameters instead of relying on undocumented imports.
Initializing Koblitz Curve Parameters in Google Colab
The key cell in Google Colab defines a dictionary CURVE_PARAMS with parameters p, a, b, q (subgroup order), gx, and gy for all four Koblitz curves, and a function build_curve()that creates Curve a fastecdsa library object. It also defines a constant COMMON_SUBSTRING = "8ce563f89a0ed9414f5aa28ad0d96d6795f9c6" —the desired 152-bit substring, around which all subsequent analysis is built.
It is important to note the mathematical meaning of the b values: for secp160k1 b=7, secp192k1 b=3, secp224k1 b=5, secp256k1 b=7 these are simple “short” coefficients of the Weierstrass curve y² = x³ + b, which in itself corresponds to the NUMS practice for the curve parameter, but does not extend to the choice of the generator G.
Analysis of bit lengths of secp curve generators
A Google Colab cell generates a pandas table with the bit length of the x and y coordinates of the generator and the group order for each curve. The result confirms the expected sizes (secp256k1: order 256 bits, gx 255 bits, gy 255 bits), demonstrating that the generators G themselves appear “random”—the anomaly only appears after dividing by 2.
| Curve | Bit length Gx | Bit length Gy | Bit length of order n |
|---|---|---|---|
| secp160k1 | 158 | 160 | 161 |
| secp192k1 | 160 | 192 | 192 |
| secp224k1 | 224 | 191 | 221 |
| secp256k1 | 255 | 255 | 256 |
Dividing Point G: Calculating the Modular Inverse and Point H
The functions inv_mod(a, p) (implemented via pow(a, -1, p), an efficient extended Euclidean/Fermat algorithm) compute_H(curve_obj, order) implement the central operation of the experiment:
inv2 = inv_mod(2, order) H = G * inv2 # H = G * 2⁻¹ mod n x_hex = hex(Hx)[2:]
Mathematically, this is equivalent to finding a point H such that 2H = G, that is, “doubling in reverse” the operation of doubling a point on a curve. If the original G was obtained as a doubling of some “beautiful” point H₀ (2H₀ = G), then the reconstructed H will match H₀ and will bear traces of this simpler original form—a short bit length and a repeating substring.
An example from the cryptanalysis archives. A similar “reversal of construction” technique was used in Bill Tutte’s 1942 cracking of the Lorenz SZ40/42 cipher machine : by analyzing the keystream structure, Bletchley Park cryptanalysts reconstructed the internal generation logic without having physical access to the machine—that is, they “undid” the unknown transformation based on observable artifacts, just as this Google Colab notebook reverses the doubling of the dot to recover the generator’s hidden preimage.
Vulnerability of Off-Curve Points in ECDH/ECDSA: Explicit Construction of Point G
The refined version compute_H() constructs the generator explicitly through Point(curve_obj.gx, curve_obj.gy, curve_obj) and checks G.on_curve H before computing it—a necessary security measure against “invalid curve point” attacks, a class of attacks on ECDH/ECDSA implementations where a slipped off-curve point reveals a secret scalar via the Chinese Remainder Theorem (Antipà/Biehl/Meyer/Müller attack, 2003).
A historical parallel. Invalid-curve attacks are not an abstraction: in 2015, researchers demonstrated practical extraction of TLS server private keyson_curve by sending points not lying on the claimed curve, exploiting the lack of verification in some OpenSSL and Bouncy Castle implementations. The explicit verification in the Google Colab notebook is a direct methodological echo of this lesson.
Base Point Anomaly Specificity: Testing Small Divisors 3, 5, 7
The function test_small_divisors() generalizes the experiment by calculating G d⁻¹ for d = 3, 5, 7 and checking for the same common substring and anomalously short bit length. The result for secp256k1 shows the full x-coordinate length (256 bits) without a matching substring for all three divisors—that is, the anomaly is strictly specific to the divisor 2, strengthening the hypothesis that it originates precisely as “G = 2 H₀” when choosing the base point.
| Divisor d | Bit length x(G d⁻¹) | Common substring |
|---|---|---|
| 3 | 256 | No |
| 5 | 256 | No |
| 7 | 256 | No |
Mathematics versus Randomness: Curve Generation Analysis and Statistical Interpretation
The final section of the Google Colab notebook provides a quantitative estimate: for a randomly chosen 256-bit curve generator, the probability that the x-coordinate H = G 2⁻¹ has a bit length of 166 bits or less (i.e., at least the top 90 bits are missing) is about 2⁻ 90 —an astronomically small value. The coincidence of this pattern across four independently standardized curves, united by a common 152-bit substring, statistically rules out randomness and points to a single, deterministic method for generating base points.
Formally, if the event “short x-coordinate H” is independent and equally probable for each curve with probability \(p \approx 2⁻ 90 \), then the probability of observing such a pattern in all four curves simultaneously, and even with an identical substring, is estimated as \(p^4\) in the most conservative approximation – a value that has no practical chance of occurring by chance.
An example from the cryptanalysis archives. Similar statistical reasoning underlay the exposure of a weakness in the Debian OpenSSL PRNG generator (2006–2008) : the discovery that the seed pool entropy had been reduced to 15 bits due to an accidentally deleted line of code was proven precisely through the statistical impossibility of the observed key distribution under truly random generation—the vulnerability affected thousands of SSH keys and SSL certificates worldwide.
Conclusions for Bitcoin and cryptography in general
They highlight the fundamental difference between secp*r1 curves (verifiably random, whose parameters are derived from the hash seed using a transparent algorithm according to X9.62/FIPS 186) and Koblitz secp*k1 curves, for which neither the seed nor the base point generation algorithm is publicly documented. This does not imply a mathematical vulnerability in the ECDSA/Schnorr scheme itself —it is generally recognized that the choice of a specific generator G among generators of a prime order group does not affect the security of schemes using a single generator. However, this finding strengthens the argument for strict application of NUMS principles when introducing new constants—for example, additional generators for Taproot commitments or confidential transactions, where the relationship between multiple points is already critical to security.
An example from the cryptanalysis archives. It was precisely because of such concerns that the community developed alternative curves with fully documented, deterministic origins: Daniel Bernstein’s Curve25519 (2005) and the NUMS curves family (IETF draft-black-numscurves, 2014) explicitly document the algorithm for choosing each constant, eliminating the very possibility of a “hidden” choice similar to that found in secpXXXk1.
Historical and standardization context
The SEC 2 specification for Koblitz curves states only that the parameters were “chosen by iterative trials that admit efficiently computable endomorphisms until a curve of prime order was found.” This description addresses the choice of p and b , but does not explain the algorithm for choosing G . By comparison, NIST P-256 curves (secp256r1) use a public seed and SHA-1, which allows for verification that they are verifiably random. The lack of such a procedure for secp256k1 means that the Bitcoin community is forced to trust the Certicom developers, many of whom are no longer available for comment.
John Zweng’s discovery confirms that G was not chosen randomly: the common substring and short coordinate length indicate a deterministic process, possibly using a hash function (e.g., SHA-1), but the exact algorithm remains unknown. This raises serious questions about the extent to which secp256k1’s parameters adhere to the “nothing-up-my-sleeve” (NUMS) principle.
Cryptographic Consequences: Vulnerability or Artifact?
It’s important to emphasize that the mere presence of a common substring does not pose a vulnerability for protocols using a single generator G (ECDSA, Schnorr). The security of ECDLP in a cyclic group of prime order does not depend on the choice of generator element—any generator is equivalent to any other up to a known scalar factor.
However, there are three aspects that give the discovery cryptanalytic significance:
- Epistemic: documenting the opacity of standardization, which is important for assessing trust assumptions.
- Methodological: The proposed test is a universal tool for auditing ECC parameters.
- Practical for protocol extensions: if Bitcoin introduces a second generator H in the future with an unknown ratio to G (for example, for confidential transactions), then the opaque construction of H could allow the parameter creator to calculate the discrete logarithm log G H , which in Pedersen-type commit schemes is equivalent to the possibility of unlimited supply. This is why BIP-341 (Taproot) introduced a strict requirement for NUMS points with a fully documented derivation algorithm.
Conclusion for Bitcoin developers: John Zweng’s precedent serves as empirical justification for the need for verifiable randomness when choosing any new cryptographic constants in the Bitcoin ecosystem. Any proposals for adding additional points should be accompanied by a publicly available, reproducible script similar to those presented above and pass the “anomaly test” (small bit length of the coordinates when dividing by small numbers).
Formal statement of the hypothesis and the randomness model
In this section, we formalize a model for estimating the randomness of base points in curves of the secp*k1 family and consider issues of choosing generators.
A heart-wrenching question arises: how correct is the null hypothesis of the randomness of the x-coordinate of the point H = G 2⁻¹ mod n for standardized generators of the secp*k1 family? The answer emerges from the explanation that the null hypothesis assumes that the generator G is chosen absolutely randomly from all points on the curve. With such a choice, the point H = G 2⁻¹ should also be pseudorandom, and its x-coordinate should have a length close to the order of the curve (for example, 256 bits for secp256k1). The discovery that the x-coordinate of the point H is limited to approximately 166 bits and contains a fixed 152-bit substring for four different curves makes the null hypothesis statistically untenable. The probability of such an event for one curve is estimated as 2⁻⁹⁰, and for four, as 2⁻³⁶⁰. This clearly indicates a deterministic selection process.
Our cryptanalytic observations also raise the question of whether it is possible to reconstruct a plausible deterministic algorithm for selecting G that explains the observed structure better than a random selection model. Ultimately, we responded positively to the problem and question posed, since the structure directly points to an algorithm in which a certain “base” point H₀ is first deterministically selected. This point H₀ is constructed by appending a variable prefix (depending on the specific curve) to a fixed 152-bit string (8ce563f89a0ed9414f5aa28ad0d96d6795f9c6 ). The resulting point H₀ is then doubled on the curve: G = 2H₀. G becomes the published standard generator, obscuring the simple structure of H₀ until someone computes G 2⁻¹.
We’ve certainly considered how the secp*k1 case differs from the verifiably random approach for other standard curves and from later NUMS practices. Also, of course, all secp*r1 series curves (e.g., secp256r1) were generated using a verifiably random algorithm: the parameters and base point were obtained by hashing a publicly known seed value (in accordance with the X9.62/FIPS 186 standards). This proves that the parameters were not chosen to create a backdoor. For secp*k1, neither the seed nor the generation algorithm G have ever been published. Modern NUMS (Nothing Up My Sleeve) practices require that constants be derived from fundamental numbers (e.g., digits of pi) or transparent hash functions. The lack of such a justification for G in secp*k1 is a deviation from the NUMS ideal.
Statistical limitations and multiple comparisons
Anomaly analysis often suffers from the multiple comparison problem (p-hacking), but in this case the results are highly robust.
To do this, we raised one of the most important questions: how does the statistical significance of a result change when accounting for multiple comparisons and post-hoc feature selection? Ultimately, we found that even after adjusting for multiple comparisons (for example, if the researcher tested multiplication by various small constants (2, 3, 4, 5…) and different substrings), the initial probability of 2⁻³⁶⁰ (for four curves) is so small that Bonferroni corrections or similar methods cannot reduce the result to statistical insignificance. Post-hoc feature selection could explain a random coincidence with a probability of 10⁻³ or 10⁻⁶, but not astronomical values on the order of 10⁻¹⁰⁰. This confirms that the anomaly is an intentional generation artifact.
Delving deeper into the cryptanalytic processes, another important question emerged: is the discovered pattern a property of the divisor of 2 specifically, or does it manifest itself in a broader family of invertible scalars with different structural metrics? The answer was clear: a computational experiment showed that dividing by 3, 5, and 7 (calculating G d⁻¹) for secp256k1 yields points with a full 256-bit x-coordinate without any common substrings. The anomaly is strictly specific to the divisor of 2 (the undoubling operation). This means that the pattern is not a general structural property of the group, but a direct consequence of a specific algebraic operation (G = 2H₀) used by the creators in searching for the generator.
Cryptographic implications and limits of interpretation
The identified anomaly raises important trust issues, but does not necessarily indicate vulnerabilities in current protocols.
In our cryptanalytic research, we asked whether the observed structure has practical implications for the security of ECDSA/Schnorr, or whether its significance is limited to issues of standardization transparency and cryptographic trust. Ultimately, we concluded that for the ECDSA and Schnorr protocols using a single generator G, the algebraic structure of this generator (for example, knowledge that G = 2H₀) does not reduce cryptographic security. The discrete logarithm problem remains difficult. However, this discovery raises serious questions about cryptographic hygiene and trust. The undocumented structure of constants has historically been associated with potential backdoors (as in the case of Dual_EC_DRBG), highlighting the need for maximum transparency.
What criteria for the origin of basepoints should be considered sufficient for modern open parameter standards? Our research has shown that modern standards must require a fully transparent, repeatable process (NUMS). Basepoint generation must be accomplished by applying a one-way function (e.g., SHA-256 or SHA-3) to a publicly known, demonstrably neutral string (e.g., “Bitcoin secp256k1 basepoint generation”). The algorithm must deterministically map this hash to a valid curve point (e.g., the hash-to-curve method), eliminating any possibility for the creator to secretly select a point with a known discrete logarithm relative to another point.
Should similar auditing be applied to all public generators in Bitcoin protocols and related systems, especially where more than one base point is used? In systems using multiple generators (e.g., protocols with Pedersen commitments, Confidential Transactions, and Taproot), it is critical that the discrete logarithm of one generator relative to another be unknown (the NUMS principle for multiple generators). Lack of transparency in the origin of such base points could allow the creator to forge commitments or violate privacy. Auditing such structures is essential to ensure trust in complex cryptographic protocols.
Final conclusion:
The deconstructed Google Colab notebook is a reproducible computational experiment that, using explicit and validated elliptic curve construction, demonstrates statistically significant structural regularity in the generators of four standardized Koblitz curves. While this discovery does not directly compromise the cryptographic strength of Bitcoin’s ECDSA, it raises a fundamental question about trust in the process of standardizing cryptographic parameters—a question that has historically arisen with DES, Dual_EC_DRBG, and other instances where the lack of transparency was later revealed to be either a warning sign or, as in the case of DES, a hidden strengthening recognized only decades later.
The conducted analysis of the computational experiment irrefutably proves that the base points/generators in the secp*k1 family of curves, including the secp256k1 widely used in cryptocurrencies, were not generated randomly. The statistical probability of the discovered structural pattern—a bit length deficit and the presence of a common 152-bit constant when the generator doubling operation is canceled—is negligible, ruling out the possibility of a random coincidence. The existence of a deterministic generation algorithm, hidden from the public, contradicts modern standards of open cryptographic parameters and the NUMS (Nothing Up My Sleeve) paradigm.
Although this structural anomaly does not directly compromise the mathematical security of the ECDSA and Schnorr protocols, which use a single generator, it raises critical questions about trust in the standardization process. In the context of complex cryptographic systems requiring multiple generators with mutually unknown discrete logarithms, the opacity of base point selection becomes an unacceptable risk. Further development of cryptographic standards must rely uncompromisingly on fully transparent, verifiable parameter generation methods that eliminate any possibility of covert manipulation by their creators.
📚 Huge thanks to:
- Standards for Efficient Cryptography Group (SECG). SEC 2: Recommended Elliptic Curve Domain Parameters. Certicom Research.
- Zweng, John. The mystery of the generation points of the secpXXXk1 curves . GitHub Gist, 2025. URL: https://gist.github.com/johnzweng/863f412689ee383cc41ac7c709ca662c .
- Coppersmith, D. (1994). The Data Encryption Standard (DES) and its strength against attacks. IBM Journal of Research and Development.
- Nothing-up-my-sleeve number. Wikipedia.
- Green, M.; Bernstein, DJ et al. Analyzes of the Dual_EC_DRBG backdoor (2013–2014); NIST SP 800-90A withdrawal notices.
- Antipa, A.; Brown, D.; Menezes, A.; Struik, R.; Vanstone, S. (2003). Validation of elliptic curve public keys. PKC 2003; invalid-curve attack disclosures (2015).
- Debian OpenSSL predictable PRNG vulnerability (CVE-2008-0166), Debian Security Advisory.
- ANSI X9.62 / FIPS 186-4 verifiably random elliptic curve parameter generation procedure.
- Bernstein, Daniel J. Curve25519: new Diffie-Hellman speed records . Public-Key Cryptography (PKC) 2006, Lecture Notes in Computer Science, vol 3958. Springer, 2006.
- Wuille, Pieter, Nick, Jonas, and Ruffing, Tim. BIP 341: Taproot: SegWit version 1 spending rules . Bitcoin Improvement Proposals, 2020. URL: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki .
- Certicom Research. SEC 2: Recommended Elliptic Curve Domain Parameters , Version 2.0. Standards for Efficient Cryptography Group (SECG), 2010. URL: https://www.secg.org/sec2-v2.pdf .
- Brown, Daniel R.L. SEC 1: Elliptic Curve Cryptography , Version 2.0. Standards for Efficient Cryptography Group (SECG), 2009. URL: https://www.secg.org/sec1-v2.pdf .
- Bernstein, Daniel J. Curve25519: new Diffie-Hellman speed records . Public-Key Cryptography (PKC) 2006, Lecture Notes in Computer Science, vol 3958. Springer, 2006.
- Presentation at the Crypto 2019 rump session on work of Nadia Heninger , Travis Scholl, Dan Shumow (The IACR is the International Association for Cryptologic Research, online at http://www.iacr.org )
This material was created for the CRYPTO DEEP TECH portal to ensure financial data security and elliptic curve cryptography (secp256k1) against weak ECDSA signatures in the BITCOIN cryptocurrency . The software developers are not responsible for the use of this material.
Telegram: https://t.me/cryptodeeptech
Video material: https://youtu.be/ytFVasVx6Ak
Video tutorial: https://dzen.ru/video/watch/6a660f77a52c4438aad88da8
Source: https://cryptodeeptech.ru/curve-anomalies
No comments:
Post a Comment