SIMD-0075: Secp256r1 Precompile (Supersedes SIMD-0048)

[0xRigel]

I've updated the SIMD to include all the things discussed in conversation on github and the core-technology channel over the past few days.

This includes:

• More specification & detail on the implementation
• New security considerations
• Citations to relevant documentation

It has become quite a bit more opinionated and therefore requires more discussion.

[0xRigel]

Tagging participants of the former discussion around SIMD-0048 for visibility
@samkim-crypto, @Lichtso , @mvines, @ripatel-fd , @sakridge

[ripatel-fd]

This looks great. I'll review in depth ASAP.

I'd also like to point out https://github.com/guidovranken/cryptofuzz as a dynamic analysis security tool.
This fuzzer has found many differences in behavior between secp256k1 ECDSA implementations and can probably be applied to secp256r1 too.

[0xRigel]

I'd also like to point out https://github.com/guidovranken/cryptofuzz as a dynamic analysis security tool. This fuzzer has found many differences in behavior between secp256k1 ECDSA implementations and can probably be applied to secp256r1 too.

Noted, thx! Will look into incorporating it into testing 🫡

[0xRigel]

I have re-written the Implementation section of the SIMD to include the pivot into using the OpenSSL crate instead of the p256 crate. Ive also added detailed implementation details as to how sig verify will be accomplished using OpenSSL.

TL;DR: Its ~3x faster than p256, is already a dependency in the labs/anza client, and uses underying C code, rather than native rust.

The idea here is to:

A. Make implementation comparison/parity between labs/anza and Firedancer easier
B. Use an rely on a more reputable and well maintained crate rather than an "unknown" and somewhat new one
C. Have faster/more efficient sigverify

Let me know what you think

[0xRigel]

Thanks @ptaffet-jump for the input, all comments with the exception of the count == 0 && length_of_data > 1 behaviour should be resolved 👍

[samkim-crypto]

Looks good to me!

It is worth noting (I apologize if this has already been discussed before) that there is going to be an inconsistency in the way ecdsa malleability is handled with the existing secp256k1 implementation, which does not handle malleability.

[0xRigel]

Looks good to me!

It is worth noting (I apologize if this has already been discussed before) that there is going to be an inconsistency in the way ecdsa malleability is handled with the existing secp256k1 implementation, which does not handle malleability.

Yep. In the description of the SIMD we made our case as to why it would be advantageous to handle malleability, but if contributors disagree I can happily remove that check to put it in line with the other precompiles
@samkim-crypto

[0xRigel]

With the approval from Anza we're just missing an approval on the FD side now 👍

[0x0ece]

I'd like to recommend the following 3 changes:

1. For the data structure, let's use the same as Ed25519.
   https://github.com/anza-xyz/agave/blob/v1.18.15/sdk/src/ed25519_instruction.rs#L22-L30
   This is because 1) Ed25519 is newer than Secp256k1, 2) it's best suited for JS impl, 3) since Webauthn supports both Ed25519 and r1, it'll make it easier to develop client libs.
   Concretely, this means switching to 2-byte instruction ids.

2. If count==0, return Error.
   This simplifies the checks and avoid unnecessary edge cases.
   Independently, I'm going to propose a SIMD to "clean up" existing precompiles and adopt this same behavior.

3. Reuse the same get_data_slice as Ed25519.
   (BTW, I personally prefer the approach outlined in this SIMD where the precompile gets data slices, and then the sigverify function is responsible for parsing data. Unlike existing precompiles that interleave fetching and parsing, that's very implementation specific.)

Other than these 3 minor changes, everything looks good to me and I can approve on the FD side.

[0x0ece]

FYI, I just opened SIMD-0152: Precompiles. The 3 changes I proposed are coherent with the new SIMD.

[0xRigel]

Adjusted the pseudocode and the data structs in accordance with @0x0ece 's comments and SIMD-0152

[0x0ece]

LGTM. I left some comments for whoever is going to develop this, but the spec looks good!

[0xRigel]

Have approval on the FD side, re-requesting approval from Anza 🫡
@sakridge @samkim-crypto

[samkim-crypto]

Looks fine to me!

[0xRigel]

Sweet, we now have approvals from both Anza and FD 🙌
Kindly asking for a merge 🫶

@joncinque @jacobcreech

[jacobcreech]

Looks like we've had approvals from current core maintainers as well as ample time to make any additional comments. Thanks @iceomatic for championing this!