conclusion.tex

\documentclass[main.tex]{subfiles}
\begin{document}

\chapter*{Conclusion}
\addcontentsline{toc}{chapter}{Conclusion}

This thesis fills the gap between highly optimized, rigid cryptographic libraries and flexible but slower interpreted computer algebra systems.
By developing a zero-external-dependency, generalized elliptic curve library in Rust alongside a ground-up mathematical exposition, this work provides both an accessible educational framework and a practical tool for experimenting with custom elliptic curves.
The mathematical exposition guided the reader from geometric intuition over real numbers to finite fields, establishing the \ac{ecdlp} as the basis of \ac{ecc}.
Exploring alternative coordinate systems and curve forms highlighted optimizations needed to avoid costly modular inversions and achieve constant-time execution.
Finally, the implementation of point-counting algorithms addressed the need to verify an elliptic curve's cryptographic suitability.

To answer \textbf{\hyperref[research_question_1]{Research Question~\ref*{research_question_1}}}, Rust's trait system and const generics effectively unify diverse mathematical models.
The \texttt{Field} and \texttt{EllipticCurve} traits abstract mathematical details into high-level interfaces, while const generics enforce compile-time type safety, preventing invalid operations like mixing elements from different fields.
However, some specialization is unavoidable.
Point arithmetic, though generic over fields, still requires curve-specific implementations due to differing formulas.
Point-counting algorithms demand field-specific implementations.
Furthermore, encoding curve parameters directly into the type would enable more ergonomic point arithmetic and type-level isomorphisms, but current compiler limitations regarding const coherence and const blocks referencing generic types prevent this approach.

Regarding \textbf{\hyperref[research_question_2]{Research Question~\ref*{research_question_2}}}, benchmarks show that Rust's zero-cost abstractions allow the generic library to slightly outperform OpenSSL on secp256k1.
Still, the generic architecture inherently limits peak performance, as it cannot exploit field- and curve-specific shortcuts used by specialized libraries.
For example, libsecp256k1 and OpenSSL's X25519 implementation exploit the prime structure of their fields.
Even so, the generic approach is performant enough for cryptographic applications where point arithmetic is not the main bottleneck.
While specialized libraries remain preferable for high-throughput workloads on standard elliptic curves, the generic approach is particularly valuable for custom elliptic curves that lack dedicated implementations.

Future work could extend the library to support Edwards elliptic curves and finite extension fields.
Point-counting performance, which currently falls behind MIRACL's schoof.cpp, could be improved via a multi-kangaroo herd optimization for the bounded \ac{ecdlp} search, and ultimately by upgrading to the Schoof-Elkies-Atkin algorithm.
Finally, as Rust's const-evaluation matures, the library can eventually evolve to a fully type-safe, compile-time-parametrized architecture, aligning the software design even more closely with the underlying mathematics.

\end{document}