Add DKLS23 presignatures

[toufic0710]

Context

bron-crypto already implements DKLS23 signing with two backends:

• signing_softspoken
• signing_bbot

In both flows, the message is only used in the last local signing step.

So part of the signing work can be done before the message is known.

Problem

Today the repo only exposes the full signing flow.

It does not expose a way to:

• precompute message-independent signing material ahead of time
• keep the result of that work
• finish the signature later once the message is known

So users who want presigning do not have a clear flow in the library. They have to use the full signing protocol even though the protocol already separates:

• work that does not depend on the message
• work that depends on the message

Suggested solution

Add a presigning flow next to the current signing flow.

This follows the direction described by Groth and Shoup for presignatures:
https://eprint.iacr.org/2021/1330.pdf

At a high level:

• each DKLS23 backend should expose a way to run all rounds that do not need the message yet
• that step should return a presignature
• the presignature should keep the secret values needed for the last step
• later, once the message is known, the caller should pass the presignature, the message, and a public randomizer to a finalize step. The finalize step should hash the message itself. It should not accept a pre-hashed digest. The finalize step should also rerandomize the presignature before producing the partial signature. The randomizer should be public and unpredictable at the time of finalization.
• that finalize step should return a normal DKLS23 partial signature, and delete the used presignature, so it can only be used once.
• Aggregate should stay unchanged

Feedback

Please let me know if this looks like the right scope and direction for the presignature work.
Please also let me know which branch or commit would be the best starting point for this work.

[aalireza]

Thanks for raising the issue.

We used to support noninteractive cases as well, but we removed it since we didn't need it. We are fine with supporting noninteractive variants again but can't implement it ourselves due to lack of time. You are welcome to take a shot at it.

In case you want to do the work, then a few points:

1. GS21 says presignature rerandomization is really only needed if you need additive key derivation or "raw signing", neither of which we support. Presignature rerandomization in the normal case will not need any rerandomization if you are okay with an additional assumption on the hash function (step 3 of An attack on ECDSA with presignatures in the paper), which we are.
2. If you still insist on presignature rerandomization, there are two tricks for it: Public beacon and hashing (section 2.5 of 2023/1019). We are okay with the 2nd approach, but I don't believe you can do it for DKLs23 (unlike, say, Lindell22) due to non-linearity.
3. Look at our historical support of noninteractive DKLs23 for example directory structure when you add noninteractive variants. Your code should have roughly the same structure. Note that pregen ceremony just means partial signature generation ceremony.
4. The design of this library is stateless, so presignature reuse (just like nonce reuse in encryption schemes) is not in scope. It is the responsability of the user to avoid reuse.

As for which branch to base your work on, always master!

P.S. You didn't ask about presignature rerandomization of Threshold Schnorr (ie. Lindell22) but if you need that as well, that one, unlike threshold ECDSA, actually needs presignature rerandomization due to 2018/417. The hashing trick for it would work and you can see how we did it before here.