Score:1

A few questions about the elliptic curves functionalities

tv flag

I've been learning about the elliptic curves and how they work, and their usage in cryptography, and I'm trying to figure out how to use them using Go.

  1. Where is the 'a' parameter from my ECC equation y^2 = x^3 + a*x + b, in this CurveParams structure? https://golang.org/pkg/crypto/elliptic/#CurveParams To verify I am understanding well please correct me if I am wrong:
  • 'P' parameter represents the order of the finite field
  • 'N' is the minimum prime number such that N*G result is the infinity point
  • 'B' is the constant 'b' in my ECC equation
  • 'Gx','Gy' represents the base point (which for example is used for calculating public keys using your chosen private key and multiplying it with G, or in the example above where N*G is used to calculate the infinity point)
  • 'BitSize' this is where I'm not sure what this actually represents. I understand that in the P256 (secp256k1 BTC) curve this is equal to 256 and so it represents the length of the private key. What I do not understand is where in the math does this number actually appear from? Or is it actually just the binary length of the 'P' ?
  • The biggest question here is where is 'a' parameter from the elliptic curve equation? How can elliptic curves actually be defined if I don't decide this parameter?
  1. What happens if you use the Double() function using a point that is not on the curve, or using the infinity point? I tried to search for some point that is not found on the curve to call the function with it but didn't find any (for the P256 curve, i searched on google) https://golang.org/pkg/crypto/elliptic/#CurveParams.Double

  2. What happens if you use the Add() function using points that are not on the curve, or using the infinity point + on curve point, or infinity point + not on curve point? https://golang.org/pkg/crypto/elliptic/#CurveParams.Add

  3. Why are private keys returned in byte types? What's the deal with the byte type? I see it used in a lot of places. Why do we not use the big int type? I see them being used in GenerateKey(), Marshal(), MarshalCompressed(), UnmarshalCompressed(), ScalarBaseMult(), ScalarMult().

For all the questions above, I am interested also from the math and programming point of view, but especially programming. If you do not have the answers for all of them, please provide any answer to any question you have answer/s for.

EDIT:

  • question 1 partially answered. BitSize still needs to be explained
Ievgeni avatar
cn flag
As far I understood, [] bytes can represent integer of size arbitrary long. The choice here seems to make no restriction to the size of the integer in ScalarMult, because it's well defined for any positive integer. And theoretically, for some specific curves; the order of the goup can be bigger than the order of the base field, then it's possible that big_int would be not enough big to represent the private key.
thebalkandude avatar
tv flag
@levegni ok it kinda makes sense.
President James K. Polk avatar
sh flag
no, the big.Int type can also represent an arbitrary sized integer. The reason to use of bytes to represent values is made clear in the documentation for Marshall, etc. There are standard formats for interchange that are defined in terms of bytes, as bytes (actually 'octets' is more accurate) are the standard unit of storage and network transmission. As to why ScalarMult and similar use the []byte form you'd have to ask the programmer, but they likely thought it would be more convenient. The big.Int type has methods to convert to and from []byte so in practice it's not an issue.
kelalaka avatar
in flag
You seem to fear about [the invalid point attack](https://crypto.stackexchange.com/q/87709/18298). The validation is necessary. The private key is a big integer that is stored as a byte object. No worries, the library handles that for you and [the conversion is easy](https://stackoverflow.com/questions/24757814/golang-convert-byte-array-to-big-int).
Score:1
cn flag

Because you know one point of the curve (the base point). you can compute $a$ :

$$a = \frac{(Gy)^2 -(Gx)^3 -b}{Gx} \mod p$$

Notice that this computation requires $Gx \neq 0 \mod p$.

About the infinity point : The infinity point is supposed to be the neutral element, then by definition of the neutral element : $(x,y)+\mathcal{O}=\mathcal{O}+(x,y) = (x,y)$, it implies thus that $2\mathcal{O}=\mathcal{O}$

And thus, Double($\mathcal{O}$) will return you the same point $\mathcal{O}$. And for the same reason, Add$(\mathcal{O}, \cdot)$, Add$(\cdot, \mathcal{O})$ are both the identity function for the set of the points of the curve.

You're not supposed to use the functions on points which are not in the curve, thus I'm assuming it should return an error, if you do that (otherwise it should).

thebalkandude avatar
tv flag
ok so this partially answeres my first 3 questions
poncho avatar
my flag
"You're not supposed to use the functions on points which are not in the curve, thus I'm assuming it should return an error" - ECC routines generally don't. Yes, they *could* check; however the time that would take would be a significant fraction of the point addition time, hence they generally don't bother for intermediate results. They really should check when you initially import the values (and when they know the initial values are on the curve, all intermediate ones will be as well); in my experience, even that isn't universal
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.