Bridge pcurves into the main elliptic curve arithmetic #4143

randombit · 2024-06-22T11:29:13Z

This results in roughly a 2x speedup for all elliptic curve algorithms, when using a supported curve.

These have a much more restrictive interface as compared to our existing EC_Point and BigInt Co-authored-by: René Meusel <[email protected]>

Co-authored-by: René Meusel <[email protected]>

This will allow switching in pcurves later

reneme · 2024-06-25T11:33:05Z

Without a full picture, yet: I think it would make sense to allow disabling the BN-based ECC implementation at compile time.

randombit · 2024-06-25T13:33:02Z

I think it would make sense to allow disabling the BN-based ECC implementation at compile time.

In principle yes I agree. However it's greatly complicated by the fact that we have large swaths of public API which expose various BigInt based ec functionality (EC_Group::multiply_mod_order, etc). This is one of those things that I think is best deferred to Botan 4 - once all of these various APIs are removed we have a much better shot at being able to do this cleanly.

reneme · 2024-06-25T14:04:41Z

To be able to get an idea of the big picture, I extended the diagram I started at some point. Feedback appreciated. :)

excalidraw.com

Note that excalidraw isn't a shared collaboration space. To publish any modifications, one has to re-create a new snapshot via "save as... > shareable link"

reneme · 2024-06-25T11:48:00Z

src/lib/pubkey/ec_group/ec_inner_data.cpp

+      std::vector<uint8_t> bytes(m_order_bytes);
+      bn.serialize_to(bytes);
+      return this->scalar_deserialize(bytes);


Suggested change

std::vector<uint8_t> bytes(m_order_bytes);

bn.serialize_to(bytes);

return this->scalar_deserialize(bytes);

return this->scalar_deserialize(bn.serialize(m_order_bytes));

reneme · 2024-06-25T11:52:03Z

src/lib/pubkey/ec_group/ec_inner_data.h

+                                                                       const EC_Scalar_Data& y) const = 0;
+};
+
+class EC_Group_Data final : public std::enable_shared_from_this<EC_Group_Data> {


Given that virtually all method implementations have the form: if(m_pcurves) { /* pcurves */ } else { /* BigInt */ } I'm somewhat inclined to suggest (yet another) virtual interface here (or perhaps instead of the EC_Scalar_Data)? But I feel you've had that idea and needed to pick the lesser evil.

That would probably be cleaner. Main issue is that even with pcurves enabled we still have to support the full set of BigInt based APIs so we're still carrying around all of the same fields. I guess we could have the pcurves EC_Group_Data derive from the generic one to avoid too much duplication ...

reneme · 2024-06-25T14:51:46Z

src/lib/pubkey/ec_group/ec_inner_pc.cpp

+void EC_AffinePoint_Data_PC::serialize_compressed_to(std::span<uint8_t> bytes) const {
+   const size_t fe_bytes = this->field_element_bytes();
+   BOTAN_ARG_CHECK(bytes.size() == 1 + fe_bytes, "Invalid output size");
+   const bool y_is_odd = (m_bytes[m_bytes.size() - 1] & 0x01) == 0x01;


Suggested change

const bool y_is_odd = (m_bytes[m_bytes.size() - 1] & 0x01) == 0x01;

const bool y_is_odd = (m_bytes.back() & 0x01) == 0x01;

reneme · 2024-06-25T15:04:31Z

src/lib/pubkey/ec_group/ec_inner_pc.cpp

+EC_AffinePoint_Data_PC::EC_AffinePoint_Data_PC(std::shared_ptr<const EC_Group_Data> group,
+                                               PCurve::PrimeOrderCurve::AffinePoint pt) :
+      m_group(std::move(group)), m_pt(std::move(pt)) {
+   m_bytes = m_pt.serialize<secure_vector<uint8_t>>();
+}
+
+EC_AffinePoint_Data_PC::EC_AffinePoint_Data_PC(std::shared_ptr<const EC_Group_Data> group,
+                                               std::span<const uint8_t> bytes) :
+      m_group(std::move(group)), m_pt(deserialize_pcurve_pt(m_group->pcurve(), bytes)) {
+   m_bytes = m_pt.serialize<secure_vector<uint8_t>>();
+}


Two things:

m_bytes could be initialized in the initializer-list as well

Suggested change

EC_AffinePoint_Data_PC::EC_AffinePoint_Data_PC(std::shared_ptr<const EC_Group_Data> group,

PCurve::PrimeOrderCurve::AffinePoint pt) :

m_group(std::move(group)), m_pt(std::move(pt)) {

m_bytes = m_pt.serialize<secure_vector<uint8_t>>();

}

EC_AffinePoint_Data_PC::EC_AffinePoint_Data_PC(std::shared_ptr<const EC_Group_Data> group,

std::span<const uint8_t> bytes) :

m_group(std::move(group)), m_pt(deserialize_pcurve_pt(m_group->pcurve(), bytes)) {

m_bytes = m_pt.serialize<secure_vector<uint8_t>>();

}

EC_AffinePoint_Data_PC::EC_AffinePoint_Data_PC(std::shared_ptr<const EC_Group_Data> group,

PCurve::PrimeOrderCurve::AffinePoint pt) :

m_group(std::move(group)), m_pt(std::move(pt)), m_bytes(m_pt.serialize<secure_vector<uint8_t>>()) {

}

EC_AffinePoint_Data_PC::EC_AffinePoint_Data_PC(std::shared_ptr<const EC_Group_Data> group,

std::span<const uint8_t> bytes) :

m_group(std::move(group)), m_pt(deserialize_pcurve_pt(m_group->pcurve(), bytes)), m_bytes(m_pt.serialize<secure_vector<uint8_t>>()) {

}

Given that m_bytes is never written to, perhaps its worthwhile to add std::span<>s that centrally refer to the segments of the serialization. That would avoid spreading the knowledge about the structure in m_bytes across several methods. Like so:

EC_AffinePoint_Data_PC::EC_AffinePoint_Data_PC(std::shared_ptr<const EC_Group_Data> group, PCurve::PrimeOrderCurve::AffinePoint pt) : m_group(std::move(group)), m_pt(std::move(pt)), m_bytes(m_pt.serialize<secure_vector<uint8_t>>()), m_bytes_x(std::span{m_bytes}.subspan(1, field_element_bytes())), m_bytes_y(std::span{m_bytes}.last(field_element_bytes())) { }

reneme · 2024-06-25T15:05:28Z

src/lib/pubkey/ec_group/ec_inner_pc.cpp

+   if(!p) {
+      abort();
+      throw Invalid_State("Failed conversion to EC_AffinePoint_Data_PC");
+   }


abort() seems a bit harsh.

Oops, was for debugging 🙈

reneme · 2024-06-25T15:07:26Z

src/lib/pubkey/ec_group/ec_inner_pc.cpp

+   auto x = BigInt::from_bytes(std::span{m_bytes}.subspan(1, fe_bytes));
+   auto y = BigInt::from_bytes(std::span{m_bytes}.last(fe_bytes));
+
+   return EC_Point(m_group->curve(), std::move(x), std::move(y));


clang-tidy says: move won't happen, because this constructor takes the BigInt objects by const&. I think, it shouldn't do that, though. Perhaps change the constructor?

reneme · 2024-06-25T15:11:34Z

src/lib/pubkey/ec_group/info.txt

@@ -11,12 +11,14 @@ brief -> "Wrapper for elliptic curve groups"
 <requires>
 asn1
 numbertheory
+pcurves


Is that really required? If pcurves is not compiled, I can still fall back to the bigint implementation also for the pcurves-supported curves, no?

Or do we want to model "no pcurves at compile time" by disabling all pcurves_* submodules?

Not really required in that if pcurves wasn't available at all we could just fall back to the generic code without issue. I'm just trying to avoid too much combinatoric explosion (more than is already in place anyway ...) with yet another module / yet more ifdef. IDK. I guess there are probably users who would prefer just using the generic code for size reasons.

reneme · 2024-06-25T15:15:33Z

src/lib/pubkey/ec_group/ec_inner_data.cpp

+         return nullptr;
+      }
+   } else {
+      BigInt r(bytes.data(), bytes.size());


Suggested change

BigInt r(bytes.data(), bytes.size());

BigInt r(bytes);

reneme · 2024-06-25T15:20:22Z

src/lib/pubkey/ec_group/ec_inner_data.cpp

+      if(auto s = m_pcurve->scalar_from_wide_bytes(bytes)) {
+         return std::make_unique<EC_Scalar_Data_PC>(shared_from_this(), std::move(*s));
+      } else {
+         throw Invalid_Argument("Failed to complete reduction of scalar bytes");


That's somewhat inconsistent. Many other methods that return a unique_ptr simply return nullptr if something fails but don't throw. Frankly, I'd prefer things to throw over passing a nullptr that I have to remember to check for.

The behavior between pcurves and the generic code are somewhat inconsistent on this - generic always succeeds no matter how big the input is. Maybe the answer here is to also introduce a (somewhat artificial) limit for the generic case so they behave the same.

randombit and others added 12 commits June 15, 2024 12:00

Add new EC_Scalar and EC_AffinePoint types

182435c

These have a much more restrictive interface as compared to our existing EC_Point and BigInt Co-authored-by: René Meusel <[email protected]>

Adapt RFC6979 generator to accept bytes

861b052

Use new EC types in ECDSA

670ff8c

Co-authored-by: René Meusel <[email protected]>

Use new EC types in ECKCDSA

a2b4b30

Co-authored-by: René Meusel <[email protected]>

Use new EC types in ECGDSA

8390739

Use new EC types in GOST 34.10

4e64e6c

Co-authored-by: René Meusel <[email protected]>

Use new EC types in SM2

8f96536

Use new EC types in ECDH

fc807a6

Use new EC types in ECIES

179c024

Hide EC Scalar and Point data behind a virtual interface

eb4f1bd

This will allow switching in pcurves later

Pcurves fixes and additions

b5b8f5d

Bridge pcurves to EC_Group/EC_AffinePoint/EC_Scalar

14e656a

randombit added this to the Botan 3.6.0 milestone Jun 22, 2024

randombit requested a review from reneme June 22, 2024 11:29

This was referenced Jun 22, 2024

Add EC_Scalar and EC_AffinePoint types #4042

Open

Replace BigInt based elliptic curve library #4027

Open

randombit changed the base branch from jack/new-ec-types to master June 24, 2024 11:26

reneme reviewed Jun 25, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bridge pcurves into the main elliptic curve arithmetic #4143

Bridge pcurves into the main elliptic curve arithmetic #4143

randombit commented Jun 22, 2024

reneme commented Jun 25, 2024

randombit commented Jun 25, 2024

reneme commented Jun 25, 2024 •

edited

Loading

reneme Jun 25, 2024

reneme Jun 25, 2024

randombit Jun 26, 2024

reneme Jun 25, 2024

reneme Jun 25, 2024

reneme Jun 25, 2024

randombit Jun 26, 2024

reneme Jun 25, 2024

reneme Jun 25, 2024

randombit Jun 26, 2024

reneme Jun 25, 2024

reneme Jun 25, 2024

randombit Jun 26, 2024

	const bool y_is_odd = (m_bytes[m_bytes.size() - 1] & 0x01) == 0x01;
	const bool y_is_odd = (m_bytes.back() & 0x01) == 0x01;

Bridge pcurves into the main elliptic curve arithmetic #4143

Are you sure you want to change the base?

Bridge pcurves into the main elliptic curve arithmetic #4143

Conversation

randombit commented Jun 22, 2024

reneme commented Jun 25, 2024

randombit commented Jun 25, 2024

reneme commented Jun 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

reneme commented Jun 25, 2024 •

edited

Loading