The Bernstein-Yang inversion code was meant to be used only with the
fields we currently use for the NIST curves.
But people copied that code and were confused that it didn't work as
expected with other field sizes.
It doesn't cost anything to make it work with other field sizes,
that may support in the future. So let's do it.
This also reduces the diff with the example zig code in fiat crypto.
Suggested by @Rexicon226 -- Thank you!
std.crypto has quite a few instances of breaking naming conventions.
This is the beginning of an effort to address that.
Deprecates `std.crypto.utils`.
Fixes compilation errors in functions that are syntaxic sugar
to operate on serialized scalars.
Also make it explicit that square roots in fields whose size is
not congruent to 3 modulo 4 are not an error, they are just
not implemented yet.
Reported by @vitalonodo - Thanks!
Use inline to vastly simplify the exposed API. This allows a
comptime-known endian parameter to be propogated, making extra functions
for a specific endianness completely unnecessary.
Most of this migration was performed automatically with `zig fmt`. There
were a few exceptions which I had to manually fix:
* `@alignCast` and `@addrSpaceCast` cannot be automatically rewritten
* `@truncate`'s fixup is incorrect for vectors
* Test cases are not formatted, and their error locations change
std.crypto.ecc: add support for the secp256k1 curve
Usage of the secp256k1 elliptic curve recently grew exponentially,
since this is the curve used by Bitcoin and other popular blockchains
such as Ethereum.
With this, Zig has support for all the widely deployed elliptic curves
today.
After P-256, here comes P-384, also known as secp384r1.
Like P-256, it is required for TLS, and is the current NIST recommendation for key exchange and signatures, for better or for worse.
Like P-256, all the finite field arithmetic has been computed and verified to be correct by fiat-crypto.
fiat-crypto now generates proper types, so take advantage of that.
Add mixed subtraction and double base multiplication.
We will eventually leverage mixed addition/subtraction for fixed
base multiplication. The reason we don't right now is that
precomputing the tables at comptime would take forever.
We don't use combs for the same reason. Stage2 + less function
calls in the fiat-crypto generated code will eventually address
that.
Also make the edwards25519 code consistent with these changes.
No functional changes.
Functions generated by Fiat-crypto are not prefixed by their description any more. This matches an upstream change.
We can now use a single type for different curves and implementations.
The field type is now generic, so we can properly handle the base field and scalars without code duplication.
