[feature request] Swappable sign/verify functions?

[jmecom]

For embedded systems with hardware accelerated ECSDA engines, it would be useful to be able to expose swappable function pointers for signing and verifying.

I have a fork which does this here.

It's a little bit weird, because the libsecp256k1 context is still initialized unconditionally. This is an okay tradeoff, IMO, because hardware accelerated Schnorr signing is extremely rare, so in practice a caller would likely still want libsecp256k1 for Schnorr, even if they are accelerating ECDSA.

Is this something that makes sense for the project to support? If so, I'm happy to clean up and test my fork and PR it.

[jgriffiths]

Hi @jmecom

Out of interest, which system are you using that has accelerated ECDSA? I'm interested if it makes much of a speed difference in practice.

I wonder about the constant-timeness of HW signing, and whether it makes sense to have this hot-pluggable via ops or would be better given as a configure argument which then compiles to use the HW directly. I'm inclined to think the latter would be preferable as in the case of e.g. --enable-mbed-tls.

[jmecom]

EFR32MG24. I did profile it at some point and it made a difference (10s of ms, iirc, but I don't have the numbers off hand)

[jgriffiths]

Nice! Do you have a link to the sdk you are using with access to the HW accelerated functionality?

[jmecom]

Yeah:

• https://github.com/SiliconLabs/gecko_sdk/blob/59d2160fe448b13730a91c0f019a8b4c53c43eb2/platform/security/sl_component/se_manager/src/sl_se_manager_signature.c#L49-L56

• https://github.com/SiliconLabs/gecko_sdk/blob/59d2160fe448b13730a91c0f019a8b4c53c43eb2/platform/security/sl_component/se_manager/src/sl_se_manager_signature.c#L128-L135

• Ref: https://www.silabs.com/documents/public/reference-manuals/efr32xg24-rm.pdf

---

For context:

• My usage: https://github.com/proto-at-block/bitkey/blob/main/firmware/lib/crypto/src/efr32/ecc.c#L43-L73
• Relevant: https://github.com/proto-at-block/bitkey/blob/main/firmware/lib/crypto/src/efr32/key_management.c#L12-L48

[jgriffiths]

Cool. So I think you'd want to add a configure argument like --enable-gecko-sdk which would use the HW signing where appropriate (e.g non-schnorr). And also probably enable the mbed-tls hashing support using the sdk too (this is already possible but may need tweaking for the geck case).

[jmecom]

That approach has two downsides that I see:

• there'd need to be a separate --flag for each additional embedded library added
• it makes the caller less flexible. Specifically, I don't directly use the Gecko SDK, instead I wrap it (primarily to normalize the signature, but secondarily to make the firmware more portable to other SDKs in the future).

The most flexible thing (but perhaps a ton of work?) would be if libsecp256k1 was treated as just one of several pluggable crypto libraries; the caller has to provide the callbacks if they want to use something custom.

I really appreciate your time thinking about this btw!

[jgriffiths]

Practically speaking, for both Liquid support, and a best-of-breed implementation we are wedded to libsecp256k1(-zkp). It's not uncommon for wally users to also directly use libsecp for things we don't expose or they want to use in different contexts (c-lightning being a classic example). Even with HW acceleration available for signing (e.g. in Jade) we wouldn't use it because there aren't likely as many eyes on it checking for bugs, backdoors, constant-time behaviour etc. That's assuming the HW impl is even meaningfully auditable, of course.

In this case, you would need libsecp for schnorr signing also, which is arguably the future of tx signing (until quantum resistance is tied down at least). So there would always be cases where the existing signing code would be used.

I'm ok with adding code to allow compilation with alternate implementations, that can be restructured/tidied up as needed if the number grows. In the event that the interface changes, this has the advantage that you don't have a runtime ABI exposed via function pointer. I agree on the loss of flexibility otherwise though. You'd want to wrap/add code for the call in wally to make the behavior match what callers expect, and also handle things like sdk versions etc which otherwise could be problematic if called at runtime via pointer. A motivating example here would be to prevent compilation with sdk versions that are known buggy for example.

I'd be interested to see the overall difference in tx signing between your impl and wally as-is with mbed-tls HW hashing enabled for your device. If you time the total signing operation including generating the signature hashes and signing each input for a typical tx I suspect the overall performance difference of the entire operation to be fairly small, and for hashing to make up a large part of the time. Especially if you do not enable low-R signatures (since they trade off signing time for size, and you appear to be optimizing for time).

[jmecom]

Agree on all points: libsecp256k1 is definitely the most audited implementation and best choice in essentially every scenario; and Schnorr sigs mean this will issue will be moot at some point in the near future too.

I'm ok with adding code to allow compilation with alternate implementations, that can be restructured/tidied up as needed if the number grows. In the event that the interface changes, this has the advantage that you don't have a runtime ABI exposed via function pointer.

Wanna make sure I'm on the same page: if a caller uses Gecko SDK (say) but wraps it their own way, how would they use libwally-core with this approach? Or am I misunderstanding?

I'd be interested to see the overall difference in tx signing between your impl and wally as-is with mbed-tls HW hashing enabled for your device. If you time the total signing operation including generating the signature hashes and signing each input for a typical tx I suspect the overall performance difference of the entire operation to be fairly small, and for hashing to make up a large part of the time. Especially if you do not enable low-R signatures (since they trade off signing time for size, and you appear to be optimizing for time).

Dug up the old numbers: signing time reduced from ~70ms to ~15ms when using hardware acceleration. Note that hashing was already hardware accelerated (in both cases). (Consider that the clock tops out at 78 MHz).

[jgriffiths]

if a caller uses Gecko SDK (say) but wraps it their own way, how would they use libwally-core with this approach?

I'm proposing that wally in this case would be your interface, for any signing calls at least - you would be free to use other functionality from the sdk in the same way e.g. Jade enables mbed-tls HW hashing in wally and then uses other mbed-tls primitives directly elsewhere in the code where this makes sense. Any extra work required to massage the sdk results into wally-acceptable form (e.g. normalizing sigs to low-S) would happen inside wally, since wally guarantees it returns low-S form.

If you wrap the sdk in some other way for your own use, that would be orthogonal to this approach.

~70ms to ~15ms when using hardware acceleration.

If that's the total (or even per-input) tx signing time then a user is unlikely to even notice that difference - given they have to accept the inputs/outputs before signing, and comms latency to return the result to the host will further make any difference smaller as a percentage of overall time.

I don't say that to dissuade you, and I'm happy to review and accept a patch to enable HW signing in this case as outlined above. But I do wonder if after enabling HW hashing this optimization is worth it (that's your decision to make of course).

[jmecom]

I'm proposing that wally in this case would be your interface, for any signing calls at least ...

Sounds good, I may prototype this; though I have other systems where I'm looking at maybe using libwally-core that don't use Gecko SDK -- so I'll need to deliberate.

If that's the total (or even per-input) tx signing time then a user is unlikely to even notice that difference - given they have to accept the inputs/outputs before signing, and comms latency to return the result to the host will further make any difference smaller as a percentage of overall time.

Ah I gave the per-input signing time; so for transactions with many inputs, it's definitely noticeable. I originally used libsecp256k1 for signing, but switched (after much thought) because of performance improvements.

But I do wonder if after enabling HW hashing this optimization is worth it (that's your decision to make of course).

As noted, I've been using HW hashing in all cases already.

[jgriffiths]

As noted, I've been using HW hashing in all cases already.

So I guess what I'm missing here is what your test code looks like - i.e. are you both hashing and signing with wally, or hashing with your own code and just signing that hash with wally.

If the former then it would be good to know what changes (if any) you had to make to enable HW hashing for wally. Otherwise, if you aren't using the wally signing code in its entirety, then you could be missing out on larger optimizations such as the signature hash caching for computing segwit v0 and taproot signature hashes which greatly speed up txs with more than one input. If you aren't using wally for key derivation, then you are likely missing the optimization to skip fingerprint computations for intermediate steps in key derivation paths, etc etc. For Jade we found these changes to be the most beneficial to improve signing speed.

[jmecom]

I should clarify: I'm not using libwally at all. Apologies for the lack of context. In my current system, I:

• Am using (a wrapper around) Gecko SDK for hashing
• Originally used libsecp256k1 directly, but now use Gecko SDK for signing

For Bitkey, the sighash is computed on the mobile app, and the hardware's only job is to sign that -- since it's a blind signer. We actually have a similar caching system too for key derivations.

For a separate project, I was considering using libwally, but noticed the inability to swap out the sign/verify functions -- and based on my prior experience knew that it might be necessary to hardware accelerate that. That's what spawned the ticket.

[jgriffiths]

Makes sense. I think if you were to prototype using wally for the full key derivation and signing process (e.g. with the python wheel), you will likely want to revisit whether or not enabling HW ECDSA is worth the effort when the total signing time is considered.

[jmecom]

Sounds good! I will profile that first, then revisit this ticket if there are noticeable performance gains from hw accel. I appreciate the back and forth!