Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provides get/set for affine coordinates on OpenSSL::PKey::EC::Point #435

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

rickmark
Copy link
Contributor

@rickmark rickmark commented Apr 4, 2021

This implements #433

Provides OpenSSL::PKey::EC::Point#affine_coords and OpenSSL::PKey::EC::Point#affine_coords= for uncompressed coords taking either an Integer or a OpenSSL::BN for set and always returns an array of OpenSSL::BN for get.

It also implements OpenSSL::PKey::EC::Point#set_compressed_coords taking an Integer or a OpenSSL::BN for the value of X and an Integer that is directly passed to EC_POINT_set_compressed_coordinates. I feel like it should be checked for [0..1] but was simpler to pass the value directly.

Rick Mark added 10 commits April 3, 2021 14:03
Use `id_` for symbols
Check OpenSSL for get/set affine coordinate functions
Able to duplicate points
Gets affine coords from a point (array of two OpenSSL::BN, x then y uncompressed)
Implemetation of setting affine coordinates
Renamed with prefix to prevent potential symbol conflicts
Number like duck types expect an even? where there is an odd?
Allows setting a OpenSSL::BN for X and the Y bit indicating if 0 if the point Y is even and 1 if the point Y is odd
Same as unary plus
Another expectation of Integer like objects that define negative?
return Qtrue;
}

rb_raise(eBNError, "ossl_bn_is_odd didn't return a boolean");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We know this is unreachable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just defensive coding 🙃

@@ -1217,14 +1248,15 @@ Init_ossl_bn(void)

rb_define_method(cBN, "initialize_copy", ossl_bn_copy, 1);
rb_define_method(cBN, "copy", ossl_bn_copy, 1);
rb_define_method(cBN, "dup", ossl_bn_dup, 0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BN implements #initialize_copy. The #dup method defined by Object should already work without this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will resolve with a comment to that effect so others know as well

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we alias +@ to #dup then?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the current state (having #+@ as a normal method defined by ossl_bn_uplus()) is fine.

ext/openssl/ossl_pkey_ec.c Outdated Show resolved Hide resolved
y = ossl_try_convert_to_bn(RARRAY_AREF(coords, 1));

xBN = GetBNPtr(x);
yBN = GetBNPtr(y);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GetBNPtr() uses try_convert_to_bn() internally. So, simply x = RARRAY_AREF(coords, 0); followed by xBN = GetBNPtr(x) should be enough.

The value from the array still needs to be stored into a separate VALUE variable (x, y) once, though.


if (point == NULL || group == NULL) {
rb_raise(eEC_POINT, "unable to get point and group");
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

point and group are never NULL. GetECPoint() and GetECPointGroup() must be checking it.

y = NUM2INT(y_bit);
} else {
rb_raise(eEC_POINT, "y_bit must be Integer");
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to explicitly check here, NUM2INT() will also do a type check (and calls #to_int if necessary).

# added in 1.1.1
have_func("EC_POINT_get_affine_coordinates")
have_func("EC_POINT_set_affine_coordinates")
have_func("EC_POINT_set_compressed_coordinates")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we have an alternate implementation in ext/openssl/openssl_missing.c using the suffixed variants? EC_POINT_get_affine_coordinates() only exists in OpenSSL 1.1.1, and the latest LibreSSL still doesn't have it.

Checking only EC_POINT_get_affine_coordinates should be good enough since it's unlikely a future LibreSSL version implements just one or two of the three functions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"alternate implementation" as in using the GFp and GF2m functions, or my nonsense encoding kludge?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant using the GFp and GF2m functions. They should both exist in OpenSSL <= 1.1.0 and LibreSSL.

Co-authored-by: Kazuki Yamaguchi <k@rhe.jp>
@@ -1217,14 +1248,15 @@ Init_ossl_bn(void)

rb_define_method(cBN, "initialize_copy", ossl_bn_copy, 1);
rb_define_method(cBN, "copy", ossl_bn_copy, 1);
rb_define_method(cBN, "dup", ossl_bn_dup, 0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the current state (having #+@ as a normal method defined by ossl_bn_uplus()) is fine.

static ID ID_uncompressed;
static ID ID_compressed;
static ID ID_hybrid;
static ID id_odd, id_even;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are not used.

@rickmark
Copy link
Contributor Author

rickmark commented Apr 15, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants