-
Notifications
You must be signed in to change notification settings - Fork 570
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
In EC keys store the data as EC_Scalar / EC_AffinePoint #4203
Conversation
89a63c4
to
fbc9b0e
Compare
fbc9b0e
to
d37a192
Compare
b5a142b
to
17e2266
Compare
ae3aed2
to
329f500
Compare
@reneme Ping on this one - this is blocking other work that I'm loathe to start knowing the merge conflicts will get messy so I'd like to get this merged within ~~ the next week if possible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Several std::move()
related nits in the constructors. I realize that the inner structure of the affected structures doesn't benefit a lot from moving. I find it good measure, nevertheless.
I tried the suggestions locally, so here's a patch, if you just want to apply it: 220ee66
EC_PrivateKey_Data::EC_PrivateKey_Data(const EC_Group& group, const BigInt& x) : | ||
m_group(group), m_scalar(EC_Scalar::from_bigint(m_group, x)), m_legacy_x(m_scalar.to_bigint()) {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving BigInt
down the from_bigint()
line would also make sense. Eventually it would end up in EC_Scalar_Data_BN
and moved in place. That would require further adaptions down this line, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this one makes sense in the long run - in fairly short order the vast majority of EC_Scalar::from_bigint
is going to throw away the BigInt
argument because it's converting the value to a PrimeOrderCurve::Scalar
instead. So it seems to me better to avoid the copy; the move optimizations will only be helpful for obscure/deprecated curves.
std::vector<uint8_t> encoding; | ||
encoding.reserve(bits.size() + 1); | ||
encoding.push_back(0x04); | ||
encoding.insert(encoding.end(), bits.rbegin() + part_size, bits.rend()); | ||
encoding.insert(encoding.end(), bits.rbegin(), bits.rend() - part_size); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps that's a good vehicle to try and use std::ranges::views
(and perhaps even integrate this with concat()
), to end up with a construction like so:
namespace v = std::ranges::views;
auto encoding =
concat<std::vector<uint8_t>>(
'\x04',
v::reverse(std::span{bits}.first(part_size)),
v::reverse(std::span{bits}.last(part_size)));
... certainly not here, though.
hash.update(group.get_a().serialize(p_bytes)); | ||
hash.update(group.get_b().serialize(p_bytes)); | ||
hash.update(group.get_g_x().serialize(p_bytes)); | ||
hash.update(group.get_g_y().serialize(p_bytes)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you wanted to avoid a few heap allocations (not sure this is worth it, though):
hash.update(group.get_a().serialize(p_bytes)); | |
hash.update(group.get_b().serialize(p_bytes)); | |
hash.update(group.get_g_x().serialize(p_bytes)); | |
hash.update(group.get_g_y().serialize(p_bytes)); | |
auto update_with_scalar = [bytes = std::vector<uint8_t>(group.get_p_bytes())](HashFunction& h, | |
const BigInt& scalar) mutable { | |
scalar.serialize_to(bytes); | |
h.update(bytes); | |
}; | |
update_with_scalar(hash, group.get_a()); | |
update_with_scalar(hash, group.get_b()); | |
update_with_scalar(hash, group.get_g_x()); | |
update_with_scalar(hash, group.get_g_y()); |
e0c6d38
to
317ee07
Compare
This is analagous to the DL scheme key types added in #3210, but here we have to retain the existing classes as we are constrained by SemVer. The new types contain both our old types (BigInt, EC_Point) and new types (EC_Scalar, EC_AffinePoint). Eventually the legacy types will be removed, but we can't do that until the next major version. GH #4027 Co-Authored-By: René Meusel <[email protected]>
In the short term we still have to retain everything in the old types since there are getters that return a const reference to those values.
#4027