[FEAT] Implement hEEA method to accelerate signature verification

[zz-sol]

Joint work with @samkim-crypto.

This PR implements the HEEA verification method in "Accelerating EdDSA Signature Verification with Faster Scalar Size Halving" (TCHES 2025).

It implements a new verification API verify_heea which mimiks the exact behaviour of verify_strict but using hEEA to accelerate the multiplications. Note hEEA also uses strict signature verification.

It also implements a three scalar fixed base multiplication scheme to harvest the performance.

Benched on a MBP M4ProMax

Ed25519 signature verification
                        time:   [16.835 µs 16.857 µs 16.880 µs]

Ed25519 strict signature verification
                        time:   [19.201 µs 19.227 µs 19.253 µs]

Ed25519 HEEA signature verification
                        time:   [15.146 µs 15.165 µs 15.184 µs]

[tarcieri]

I will need to read the paper, but I was a little confused by this:

It implements a new verification API verify_heea which mimiks the exact behaviour of verify_strict but using hEEA to accelerate the multiplications. Note hEEA also uses strict signature verification.

I saw there was a similar pull request to ed25519-zebra: ZcashFoundation/ed25519-zebra#200

mimiks the exact behaviour of Zebra's verify but using hEEA to accelerate the multiplications.

...so is that implementing the ZIP-215 rules?

I'm confused because ZIP-215 is more permissive than RFC8032, and verify_strict is less. Did you adapt hEEA to work with ZIP-215 for the ed25519-zebra case, or is there something I'm missing?

[zz-sol]

I will need to read the paper, but I was a little confused by this:

It implements a new verification API verify_heea which mimiks the exact behaviour of verify_strict but using hEEA to accelerate the multiplications. Note hEEA also uses strict signature verification.

I saw there was a similar pull request to ed25519-zebra: ZcashFoundation/ed25519-zebra#200

mimiks the exact behaviour of Zebra's verify but using hEEA to accelerate the multiplications.

...so is that implementing the ZIP-215 rules?

I'm confused because ZIP-215 is more permissive than RFC8032, and verify_strict is less. Did you adapt hEEA to work with ZIP-215 for the ed25519-zebra case, or is there something I'm missing?

hEEA is generic method to accelerate double scalar base multiplication; it does not change how signature verification works.
I adapt hEEA for both ed25519-dalek and ed25519-zebra (ZIP-215).

• this PR: hEEA arithmetics; and apply hEEA for verify_strict
• zebra PR: apply hEEA for zerba's verification.

ed25519-zebra requires curve25519-dalek which is why that PR depend on this.

[tarcieri]

@zz-sol I guess the other question then is why not apply it to the RFC8032 verification as well, but only to verify_strict?

[zz-sol]

RFC8032

good point. It does. Let me add those

[zz-sol]

@zz-sol I guess the other question then is why not apply it to the RFC8032 verification as well, but only to verify_strict?

I take it back. Turns out that you cannot apply hEEA for raw_verify.

The reason is that in hEEA you are doing a three scalar mul where R is one of the bases. So if R is of low order this TSM is buggy.

[rozbb]

This is very cool, thank you for your work! I’ll state my opinion here: this is a lot of new code to take on, and nontrivial code at that. I don’t think I’d feel comfortable maintaining this.

Do you think it’d be possible to refactor this as a crate external to dalek? If not, what primitives would you need exposed? I’d like to help if possible

[tarcieri]

One thing that might help is splitting up the PR into one that just adds vartime_triple_scalar_mul_basepoint without anything else, which would make it easier to review

[zz-sol]

This is very cool, thank you for your work! I’ll state my opinion here: this is a lot of new code to take on, and nontrivial code at that. I don’t think I’d feel comfortable maintaining this.

Do you think it’d be possible to refactor this as a crate external to dalek? If not, what primitives would you need exposed? I’d like to help if possible

One thing that might help is splitting up the PR into one that just adds vartime_triple_scalar_mul_basepoint without anything else, which would make it easier to review

I think a lot of the code are adding pre-computed table for B*2^128 and a lot of tests. The actual new logic should not exceed a few hundred lines of code.

I can break them down to

• tsm core functions
• table constants
• heea verification

would this be helpful?

Do you think it’d be possible to refactor this as a crate external to dalek?

my hope is that this gets integrated and gets renamed to verify_strict eventually -- it offers pure performance gains and does not change existing verify_strict logic.

[tarcieri]

@zz-sol how about putting the constants in one commit and the core functions in another commit in the same PR to make it easier to review just the latter, and then saving the verification implementation for a followup PR?