Risc0 Acceleration for Curve25519

[jjtny1]

Closes: risc0/risc0#721

Use Risc0's accelerated multiplication circuit in the Curve25519-dalek library. This speeds up Ed25519 signatures.

Majority of these changes live in src/backend/serial/risc0. This folder contains implementations of:

1. FieldElement over 2**255 - 19
2. Scalar implementation mod 2**252 + 27742317777372353535851937790883648493 (the order of the subgroup of points with base x = 9)
3. Constants

Cargo uses these FieldElement, Scalar and Constant implementations from the risc0 folder when compiled for the zkvm.

Initial benchmarks using sample guest code results are:

Scalar operations:
add: 836 cycles

Scalar operations:
mul: 779 cycles

Scalar operations:
square: 779 cycles

Scalar operations:
negate: 500 cycles

Scalar operations:
invert: 84981 cycles

Group operations:
vartime_double_scalar_mul_basepoint: 963496 cycles

Without acceleration:
Scalar operations:
add: 786 cycles

Scalar operations:
mul: 3121 cycles

Scalar operations:
square: 4215 cycles

Scalar operations:
negate: 1812 cycles

Scalar operations:
invert: 318714 cycles

Group operations:
vartime_double_scalar_mul_basepoint: 2915045 cycles

And signature verification:

With Acceleration:
Verification: 1112088 cycles

Without Acceleration:
Verification: 3214543 cycles

How was this tested:

1. Using @nategraf's branch, I ran CARGO=/Users/jobythundil/.cargo/bin/cargo cargo-risczero risczero test -- --release --no-default-features from the curve25519-dalek crate to run all the unit and integration tests

2. Using this guest modeled after our ecdsa example to run basic group operations and signature verification: https://github.com/jjtny1/curve25519-dalek-test/tree/main/methods/guest/src/bin

[jjtny1]

These constants are taken from the u64/u32 existing implementation (https://github.com/risc0/curve25519-dalek/blob/main/curve25519-dalek/src/backend/serial/u64/constants.rs)

[jjtny1]

This library does not build in the zkvm. It's only used for benchmark tests

[jjtny1]

This file implements a custom FieldElement type that uses risc0::mod_mul

[nategraf]

I like how simple the core of this PR is. It looks like the biggest lift is indeed in curve25519-dalek/src/backend/serial/risc0/field.rs.

As far as I can see, you are always using the normalized form of the modular multiplication functions, which is the right baseline. However, within the field implementation is should be possible to speed things up by using the denormalized form for multiplication and adjusting addition and other methdods to handle the fact that inputs may be greater than the modulus. (In particular, there will be exactly two representations of any given number).

The field implementation in the k256 PR can provide some idea of what I mean:

https://github.com/risc0/RustCrypto-elliptic-curves/blob/44b1fc2b317e76bb150636cf67d0fbdfcac39601/k256/src/arithmetic/field/field_8x32_risc0.rs#L137-L181

Additionally, if the benchmark cycles numbers you sent before are accurate, there is something that is not being accounted for that is driving up field arithmetic costs. As a reference, here is the results from cargo run --bin benchmark in the k256 ECDSA example. ("Field" below means the k256 base field and "Scalar" means the scalar field).

Field operations:
add: 169 cycles
mul: 39 cycles
mul_single: 1142 cycles
square: 39 cycles
negate: 31 cycles
invert: 9328 cycles

Scalar operations:
add: 225 cycles
mul: 147 cycles
square: 147 cycles
negate: 123 cycles
invert: 17200 cycles
invert_vartime: 17201 cycles

Group operations:
lincomb: 861568 cycles

I would expect the ed25519 base field performance to be at least as good as k256. (Note, not exactly sure why mul_single is over 1000 cycles. My guest is that there is a page-in that is not being removed from the cycle count)

Could you point me to your benchmark implementation so that I can try it out?

[jjtny1]

Could you point me to your benchmark implementation so that I can try it out?

Ive been using this: https://github.com/jjtny1/curve25519-dalek-test
and i run it with cargo run --bin benchmark @nategraf

[nategraf]

I get this warning when compiling the guest. Can you add the RISC Zero target in build.rs to suppress this warning?

ed25519_verify: warning: "Defaulting to curve25519_dalek_bits=32: Unknown Rust target platform."

I also opened a PR against your branch with some fixes jjtny1#1

[nategraf]

Could you gate these behind a cfg(not(target_os = "zkvm"))? Goal being that building this fork for the host should be essentially the same as upstream

[jjtny1]

Do you mean cfg(target_os = "zkvm")

[nategraf]

Ah, yes that's what I meant

[nategraf]

Ready to merge! Thanks for driving this