0
$\begingroup$

Consider ed25519 signing (RFC 8032).

There, the private key is a 32-byte random value, and for signature generation, the 32-byte private key is first hashed and then the secret scalar and nonce are derived from the hash.

Now, in threshold ed25519 (RFC draft), the thresholdized private key is the scalar (and the nonce is derived non-deterministically during the protocol execution). A 32-byte private key as in RFC 8032 does not exist.

Question: If we wanted to use thresholdized ed25519 but still be able to export private keys that are compatible with ed25519 from RFC 8032, what would we do?

$\endgroup$

1 Answer 1

1
$\begingroup$

Frost with the ciphersuite: "FROST-ED25519-SHA512-v1" is made to be fully compatible with RFC8032 from the verifier's perspective. The difference is that this TSS does not have deterministic nonces. Nonce generation isn't relevant to verification (as long as it's done securely to prevent key recoveries). A naive deterministic nonce in the TSS setting could also lead to key recovery.

On exporting the secret key: The secret key exists "somewhere"; otherwise, we couldn't make verifiable signatures. But the point of TSS is to prevent the signing key from being reconstructed somewhere. You can always reconstruct the secret key if you have enough information.

  • Trusted dealer for key generation: The trusted dealer knows the secret values used in the Shamir Secret Sharing scheme.
  • Distributed Key Generation: If one controls more parties than the threshold, then it is possible to apply the recovery algorithm to recover the shared secret from each share. Typically, this is just Lagrange interpolation.
$\endgroup$
5
  • $\begingroup$ Thanks for the reply! Unfortunately, it doesn't tackle the core of my question: "If we wanted to use thresholdized ed25519 but still be able to export private keys that are compatible with ed25519 from RFC 8032, what would we do?" That is, assume we want to export the secret key, and we want to do it in a way that it can be fed into existing ed25519 implementations, what would we do? $\endgroup$
    – mti
    Commented Jan 22 at 14:45
  • $\begingroup$ @mti as explained in the answer, there reason standard ed25519 looks that way is to support deterministic nonce. This is a feature we actually want to avoid for security reason, the threshold setting. In the "trusted dealer" scenario what you could do is generate the "seed" $k$, use SHA512 to compute $s$ and the PRF key used for deterministic nonce generation. Then the trusted dealer would be able to use an existing implementation without issue. Note again, that you can't give the nonce PRF key to the TSS parties, that will be catastrophic. $\endgroup$ Commented Jan 22 at 15:20
  • $\begingroup$ But arguably, the trusted dealer should not keep the key material around. In a basic DKG setting, what you are asking appears impossible, as it requires being able to compute preimages of $s$ and the nonce PRF key. So even if you recover enough SSS shares, you now need to find a value $k$ such that $SHA512(k) = (s, value)$. This is intractable based on our current understanding of SHA512. And in general, for a good PRF or random oracle (depending on how you see it), random preimages are infeasible. $\endgroup$ Commented Jan 22 at 15:26
  • $\begingroup$ Thx for elaborating. So it seems like another option would be to use a DKG that computes sha512 in MPC and outputs secret shares of the private scalar and the nonce. However, that would probably be a much less efficient DKG than typical elliptic curve DKG protocols. $\endgroup$
    – mti
    Commented Jan 22 at 15:36
  • $\begingroup$ @mti yeah I read of solutions using MPC to support deterministic signatures. But yeah, I can imagine this adds quite a bit of overhead. The issues are that for each signing session, you'd need an MPC protocol to compute anything involving SHA512 and the shared nonces. Maybe this can be efficient but at least less efficient than probabilistic signatures. $\endgroup$ Commented Jan 22 at 15:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.