In Elliptic Curve Cryptography, we need a base Point G to generate all other Points aka Public keys.
The order of G must be a prime and should be as large as possible.
Thus, there more private keys for us to choose.
But how can I find a best or good enough G, and how to get the order of G quickly;
order • G = Zero;
For example, on the Secp251k1 curve.
The Order n = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
the Base Point G.x = 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798
how did the designer of secp251k1 know this?
I found Generate base point ( G ) of elliptic curve for elliptic curve cryptography.
It seems the solution is not efficient.
Related
I tried to observe / implement the discrete logarithm problem but I noticed something about it; but before I get into it let me give some clarification which is open to correction.
a = b^x mod P
Where as
a = the public key of the address;
b = the generator point of the secp256k1 koblitz curve (this is the
curve in context);
x = the discrete log;
P = the modular integer.
I coupled all parameters below:
A =
044f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1
(uncompressed public key)
034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa :
(compressed public key)
B = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B
16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419
9C47D08F FB10D4B8 (uncompressed generator point)
02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B
16F81798 (compress generator point)
X = ?
P = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE
FFFFFC2F
I don't actually know what part of the parameters I should use ( compressed or uncompressed)
N. B : I tried the uncompressed public key to Mod P but the uncompressed public key exceeded the Mod P in size.
What should I do about this?
a = b^x mod P Where as
a = the public key of the address;
b = the generator point of the secp256k1 koblitz curve (this is the
curve in context);
x = the discrete log;
P = the modular integer.
We are given a discrete logarithm problem (DLOG) ( also called the index calculus ); That is given a, b, and P find x such that a = b^x mod P is held. The above is actually the multiplicative notation for finite field DLOG as used by OP. ECC DLOG is additive and has different notation as;
That is given points A and the base B find x such that A = [x]B is held on the curve E(FP). [x]B simply means that add the point B x-times to itself.
Compression
The beginning byte provides information about compression.
02 compression and choose y
03 compression and choose -y
04 No compression
To find the y, put the x into the curve equation and solve the quadratic residue by the Tonelli-Shanks algorithm.
In your case, both are given, no problem. Use the uncompressed public key.
The current record for secp256k1 is 114-bit On 16 June 2020 by Aleksander Zieniewic and they provided their software. So, if you don't have a low target, you cannot break the discrete log.
I tried the uncompressed public key to Mod P but the uncompressed public key exceeded the Mod P in size.
A point Q in the Elliptic curve when used affine coordinate system it has two coordinates as Q=(x,y) where x,y from the defining field (P in your case). When checking a point Q is either on the curve or not put x and y into the curve equation y^2 = x^3+ax+b and check the equality.
To uncompress insert the value of x into the equation x^3+ax+b mod P to get let say value a, then use the Tonelli-Shanks algorithm to find the square root of a in this equation y^2 = a mod P to find y and -y. According to compression value choose y or -y.
update per comment
I tried using the compressed public key but it was still bigger than mod p.
Compression a point requires information about what is the compression. Now you have given two forms of the public key a;
No compression: since the beginning starts with 04
Compression but choose the -y since starts wiht 03
Using capitals here not to confuse with hex a;
A = 04
4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1
A = 03
4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
You can use the curve equation to derive the second part with chosen -y
And you can compare the coordinate values with
p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
a = 0x4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
if a>p:
print("a")
or use yours eye and mind;
P = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
x(A)= 4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
y(A)= 385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1
I have implemented the Serial Pollard Rho Algorithm for solving Elliptic curve discrete log problem . Now I am try to parallelize it using the Parallel Pollard Rho Algorithm.
so I just need some help to understand what kind property I can use for selecting distinguished points for collision detection. It would be a great help if some examples can be suggested also.
You could use any property. The thing to get right is the probability for some point to be a distinguished point. For example if we want one distinguished* point per 2^32 points, we could define a distinguished point as a point which has all last x 32 bits 0.
For example in Sage with point P:
>>> P.xy()[0].lift() & 0xffffffff == 0
True/False
In the normal case, this will do, but I admit that this is not really ideal when you are calculating elliptic curve arithmetic in a projective or Jacobian coordinate system, because you will have to do an inversion for every distinguished-point-test.
I am attempting to create the properly DER encoded ECC parameters for the custom Microsoft P160 PlayReady curve to feed into a HSM. I have found a few sources that specify the definition of the P160 curve since it is non-standard and custom. Below is a link to one source. In particular, the PlayReady curve values are discussed in Section 6.4.2 of the book Elementary Number Theory,A Computational Approach by William Stein.
Below is an exert from another source concerning the P160 PlayReady curve parameters.
For ECC, Microsoft is using an elliptic curve over Zp, where p is a
160 bit prime number (given below). The curve consists of the points
that lie on the curve y^2=x^3+ax+b, where the operations are done over
the field Zp and a and b are coefficients that are given below.
All values are represented as packed binary values: in other words, a
single value over Zp is encoded simply as 20 bytes, stored in little
endian order. A point on the elliptic curve is therefore a 40 byte
block, which consists of two 20 byte little endian values (the x
coordinate followed by the y coordinate). Here are the parameters for
the elliptic curve used in MS-DRM:
p (modulus): 89abcdef012345672718281831415926141424f7
coefficient a: 37a5abccd277bce87632ff3d4780c009ebe41497
coefficient b: 0dd8dabf725e2f3228e85f1ad78fdedf9328239e
generator x: 8723947fd6a3a1e53510c07dba38daf0109fa120
*generator y: 445744911075522d8c3c5856d4ed7acda379936f
Order of curve: 89abcdef012345672716b26eec14904428c2a675
These constants are fixed, and used by all parties in the MS-DRM
system. The "nerd appeal" of the modulus is high when you see this
number in hexadecimal: it includes counting in the hexadecimal, as
well as the digits of fundamental constants e, pi, and sqrt(2).
Based on this information I have created the following hex-encoding of the DER encoded curve parameters for the P160 curve using BouncyCastle as my base ASN.1 library. Note that no seed value is specified in these curve parameters.
308195020101302006072a8648ce3d010102150089abcdef012345672718281831415926141424f7302c041437a5abccd277bce87632ff3d4780c009ebe4149704140dd8dabf725e2f3228e85f1ad78fdedf9328239e0429048723947fd6a3a1e53510c07dba38daf0109fa120445744911075522d8c3c5856d4ed7acda379936f02150089abcdef012345672716b26eec14904428c2a675
Although mathematically these curve parameters are accepted by the HSM and OpenSSL, the P160 curve points produced are not acceptable to PlayReady. I am able to use the same process to produce valid P256 curve points that are acceptable to PlayReady so I do no believe my methods are flawed. Does anyone have any experience with the PlayReady P160 curve parameters?
After researching with Microsoft the solution was found. Apparently one must byte swap the public key x/y points, and the private key to get the PlayReady tool kit to accept the EC key pair only for the P160 curve. This odd byte swapping was not required for the P256 EC key pair.
I`m trying to implement ECDSA in the curve secp256k1 in Google Go.
Secp256k1 is defined by the SECG standard (SEC 2, part 2, Recommended Elliptic Curve Domain Parameters over 𝔽p, page 15) in terms of parameters p, a, b, G compressed, G uncompressed, n and h.
In Go's crypto library, the curves are defined by parameters P, N, B, Gx, Gy and BitSize. How do I convert parameters given by SECG into the ones needed by Go?
In the elliptic package of Go,
A Curve represents a short-form Weierstrass curve with a=-3.
So, we have curves of the form y² = x³ - 3·x + B (where both x and y take values in 𝔽P). P and B thus are the parameters to identify a curve, the others are only necessary for the operations on the curve elements which will be used for cryptography.
The SECG standard SEC 2 defines the secp256k1 curve as y² = x³ + a·x + b with a = 0, i.e. effectively y² = x³ + b.
These curves are not the same, independent of which b and B are selected here.
Your conversion is not possible with the elliptic package's Curve class, as it only supports some special class of curves (these with a = -3), while SEC 2 recommends curves from other classes (a = 0 for the ...k1 curves).
On the other hand, the curves with ...r1 in the name seem to have a = -3. And actually, secp256r1 seems to be the same curve which is available in elliptic as p256(). (I didn't prove this, but at least some the hex digits of the uncompressed form of the base point in SEC 2 are the coordinates of the base point in elliptic.)
I've googled the following URL's and need more simple information regarding Bilinear Maps
Intro to Bilinear Maps -- by Bethencourt and
http://en.wikipedia.org/wiki/Bilinear_map
Lecture 25: Pairing-Based Cryptography -- MIT course
I would like to know in a simple to understand framework
1) what is a bilinear pairing -- an example would be great
2) how is it useful say in CP-ABE -- ciphertext policy attribute based encryption schema
Thanks
A pairing, in cryptography, is a way to make three-party operations.
Suppose that you have three groups G1, G2 and G3, in which discrete logarithm is hard. Let's note group operation additively (with a '+' sign) in G1 and G2, and multiplicatively in G3. A pairing e is a function which takes one element of G1 and one element of G2, and outputs an element of G3, such that, for all integers a and b, and all group elements X1 and Y1 (from G1) and X2 and Y2 (from G2), you get:
e(X1 + X2, Y1) = e(X1, Y1) e(X2, Y1) (pairing is linear in the first parameter)
e(X1, Y1 + Y2) = e(X1, Y1) e(X1, Y2) (pairing is linear in the second parameter)
e(aX, bY) = e(X, Y)ab (actually a consequence of the bilinearity explained above)
An example of a very weak pairing is the following: let p and q be two prime numbers such that q divides p-1. Let g be a multiplicative generator of a sub-group or order q modulo p (i.e. g is not 1, but gq = 1 mod p). Define G1 and G2 to be the integers modulo q, with addition as group operation. Define G3 to be the subgroup generated by g. Then, define e as: e(X, Y) = gXY mod p. This gives you a non-degenerate pairing ("non-degenerate" means that the pairing can return values other than 1). But it is useless for cryptography because "discrete logarithm" in G1 and G2 is a matter of a simple modular division, i.e. very easy to compute efficiently (because we used integer addition as group law).
A non-weak pairing can be used for identity-based cryptography (where the public key of someone is their email address, not some mathematical object linked to the address through a signed certificate -- the point being, precisely, to avoid a PKI). It can also be used for three-party Diffie-Hellman, or more generally protocols which involve three entities at a time (e.g. protocols for "electronic cash" or some voting systems). See this page for some details and links.
The currently only known cryptographically strong pairings, but still usable in practice, are based on specially crafted elliptic curves. See Ben Lynn's PhD dissertation for a mathematical introduction, and PBC for the implementation. An "easy" variant will make G1 and G2 an elliptic curve over a field GF(p) (for a prime integer p), and G3 will be a multiplicative subgroup of the invertible elements in GF(p2). Be warned that it is somewhat higher-level mathematics than "plain" elliptic curves (you have to know how field extensions work).