1

ECDSA can be instantiated with a variety of different elliptic curve groups.

Two example curves are secp256k1 and edwards25519.

Question: Assume we have a secret key scalar generated for secp256k1. Is it OK to use this scalar for ECDSA over edwards25519?

mti
  • 655
  • 3
  • 12
  • 1
    In general, we are not advising using a key for multiple purposes. If you need, have a master key and drive two keys by using a good key derivation function like HKDF. If you are using a key for more than one purpose, a simple question what if you lost the secrecy of your key ( software problems, shoulder sniff) then all of your signatures are lost! – kelalaka Jan 23 '24 at 11:33
  • Yes, I know that. This is discussed in https://crypto.stackexchange.com/questions/54660/is-it-safe-to-use-same-private-key-in-two-or-more-ec-signature-algorithms. However, I'm more interested in the theoretical implications. Assume we are given an entropy source that produces secp256k1 scalars. Would it be safe to use these directly with a scheme that expects edwards25519 scalars, in general? (Maybe I should have phrased my question better in that way...) – mti Jan 23 '24 at 11:36
  • 3
    edwards25519 is more often associated with EdDSA than with ECDSA. These are significantly different algorithms (e.g. in EdDSA a representative of the ephemeral Elliptic Curve point is in the input of the hash, it's not in ECDSA). It's not clear to me how ECDSA on edwards25519 works (or would work). Perhaps the question is: what if we use a private key scalar intended for ECDSA on secp256k1 as one for EdDSA on edwards25519 ? Or is the question strictly with ECDSA, e.g. on secp256k1 and secp256r1 ? – fgrieu Jan 23 '24 at 11:54
  • In the general scenario, it seems also not great to reuse keys across curves. If one group is slightly larger than the other, then the naive approach to reuse a key would incur distribution biases. There are some results for joint security of say x25519+ed25519 showing that reuse is OK. But I am not aware of a general result. Interesting theoretical question, but the advantage is very unclear even in the theoretical sense. – Marc Ilunga Jan 23 '24 at 12:30
  • @fgrieu, ECDSA works over different curves, not just secp256k1, right? But, yes, you could ask a similar question about ECDSA and EdDSA. – mti Jan 23 '24 at 22:47
  • 1
    @MarcIlunga The background is as follows. Assume we have a distributed key generation protocol that produces secret-shared scalars over a certain range. It is already implemented and not easy to swap out / modify. Could we use the scalars produced by the DKG in a scheme that has a slightly different curve order? – mti Jan 23 '24 at 22:49
  • @mti, thanks for the clarifications. I think the DKG detail would help the question be clearer. Now, DKG protocols are quite generic, so it should not be too hard to modify them. You probably would want that implementation to be audited as well. I can only imagine it being hard if the users don't have in-house experience. In which case, I wouldn't advise trying to cut corners. Have you searched for (good) libraries for FROST? They might include a proper DKG implementation. Why not pay a qualified cryptography engineer to do the job? – Marc Ilunga Jan 23 '24 at 23:38
  • @MarcIlunga, it's not just about paying a cryptography engineer. There is maintenance costs and added complexity and so on. Also, I didn't want this to be a meta discussion about what other options there are. I'm really more interested in the theoretical implications. Probably one could reason about the two systems being indistinguishable as long as the key distributions are close enough or something like that... – mti Jan 24 '24 at 00:05
  • 1
    @mti I did indeed say before that this is an interesting question on its own right. But, I think it's fair to say that the practical motivations described earlier matter quite a bit and make the question a bit more specific. Briefly, on your first objection, I think this applicable to basically anything. For the curves in question. The DKG output is a 256-bits value, whereas the target order is 253 bits. This introduces a modulo bias and the distribution is bad. However, if the initial curve had a 512 bit order, the distribution is close to random even after reduction. – Marc Ilunga Jan 24 '24 at 00:35
  • What exactly is envisioned matters. For a start, "secret key" is not the same as "secret key scalar": the former is transformed to the later per conventions that vary according to context. In particular, in EdDSA with edwards25519, that conversion involves a SHA-512 hash then converted to integer little-endian with bit masking, when in ECDSA there's no hash and the conversion is big-endian (and reversible, contrary to EdDSA). ASN.1 decoration also differs. Thus indentical private keys do not lead to identical scalars, or vice-versa. And we can't make an EdDSA private key for a given scalar. – fgrieu Jan 24 '24 at 16:37
  • @fgrieu I'm aware and totally agree. I tried to leave that part out of the question by fixing the considered scheme to be ECDSA. And I wanted to give a concrete scheme as an example to make the question more tangible and concrete. Anyhow, this actually might have led to more confusion overall. Maybe it's just a silly question ‍♂️ – mti Jan 25 '24 at 13:30
  • @MarcIlunga Yeah, at the bottom of my question kind of was/is: In which circumstances can we tolerate the modulo bias? What are the boundaries here? Then it might boil down to a simple mathematical question about the indistinguishability of the scalar distributions (for which I just don't have a general answer at hand and thought somebody could help). However, as explained in my reply to fgrieu's comment, I tried to make the question more concrete thinking this would help. Unfortunately, it seemed to have led to more confusion. – mti Jan 25 '24 at 13:40
  • @mti in this concrete case involving TSS, I think it's clear that reusing the keys between curve can only be done by reducing existing shares modulo ed25519. So we ignore SHA512 key derivation for now. A tool to judge here if this works is using statistical distance (see Wikipedia). In my calculation (please double check!!!), the distance is at about $2^{-127}$. Which is cryptographically acceptable. But this doesn't mean it's a good idea. And there are many issues to apply it to your distributed setting: including how is the new public key generated. Maybe you can solve it with a ZkPOK. – Marc Ilunga Jan 25 '24 at 15:42
  • In the general case, I think it's sufficient to reduce a scalar modulo the order of the other curve as long as the statistical distance is ok. Then, if needed generate, a nonce PRF key at random. I think the KDF part isn't essential besides compatibility and key management. But if you've got good source of randomness, you may as well seed a PRG and to things normally from there onward. – Marc Ilunga Jan 25 '24 at 15:46
  • 1
    For future reference, I derived and wrote down the general closed formula for computing the modulo bias. https://crypto.stackexchange.com/questions/109521/modulo-bias-how-to-compute-statistical-distance/109522#109522 Please have a look if that checks out. @MarcIlunga – mti Jan 27 '24 at 22:06

0 Answers0