1
$\begingroup$

Regarding SubtleCrypto and curves P-256, P-384 and P-521.

Can I mix two different curves for key derivation? For example performing key derivation between P-256 and P-521.

EDIT: Can I mix two different curves to derive data? (So not to derive keys, it is not what I meant)

Improve this question
$\endgroup$
6
  • 1
    $\begingroup$ Well, I think the simple answer is no: both sides need to use the same parameters. Nothing mysterious about that. Within e.g. TLS 1.2 the parameters are indicated by OID. In the link P-256 is indicated by secp256r1 which is the commercial name of the same curve. $\endgroup$ – Maarten Bodewes♦ Jan 9 at 0:05
  • 1
    $\begingroup$ SubtleCrypto.deriveBits or deriveKeys supports 3 algorithms, but the only one using EC is ECDH, and yes ECDH requires both parties use (keypairs on) the same curve. @MaartenBodewes nit: the TLS identifiers (actually valid for 1.0-1.2 before 8422, although EC is rarely supported on implementations that don't also support and prefer at least 1.2, with a subset still valid after 8422 and in 1.3) are not OIDs -- but the curves themselves remain incompatible no matter how you identify them. $\endgroup$ – dave_thompson_085 Jan 9 at 3:38
  • $\begingroup$ Thank you for your answer @dave_thompson_085! $\endgroup$ – Tomas Jan 9 at 15:54
  • $\begingroup$ Oh, yeah, they are one byte identifiers, I forgot already. Fortunately everything before 1.2 is on the way out and 1.3 starts to be supported by all software that keeps reasonably up to date. $\endgroup$ – Maarten Bodewes♦ Jan 9 at 17:00
  • $\begingroup$ I don't know how you are planning to mix them but if you are talking about ECDH then no, it is not possible. Each side only uses one curve, one base point, One ECDH public key point and one scalar to derive a shared secret point. Another party's ECDH public key point sent, won't even be interpreted as same point if used with another curve, i.e. if only the x coordinate and the sign are sent, otherwise the point on one curve will likely be rejected right away as not even being on another curve. $\endgroup$ – Manish Adhikari Jan 10 at 9:56
2
$\begingroup$

No, it is not possible to mix domain parameters / curves when performing key derivation.

First of all, the implementations are likely to fail if they find curve identifiers. These can be single protocol specific bytes, OID's or named curves or full parameter sets, depending on the protocol.

Second, it is very likely that implementations will reject the public key value if the key value identifies the curve. It might also be that the key is related to the curve field (at least 2x curve field size for uncompressed keys and 1B + 1x curve field size for compressed keys).

Thirdly, it should try and see if the point is actually on the curve, it is very possible that this fails as well, if the implementation is correct. Some curves are designed in such as way that such checks are not necessary.

Finally when the operations are performed then the calculations would result in a non-matching "shared" secret. Subsequent validation that the shared secret is valid would fail (e.g. using an explicit MAC calculated from the shared secret or the first message MAC, usually from derived keys).

So no, you cannot "mix curves" in general, there needs to be some way to make sure that both sender / receiver use the same set of domain parameters / curve. This is rather independent of SubtleCrypto, of which I'm not a full expert (but it is a rather generic cryptographic API, so yeah).

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ As a comparison, it's like asking if you could use coordinates for one coordinate system for another coordinate system. Even if they make sense, they likely won't get you the same location. $\endgroup$ – Maarten Bodewes♦ Jan 9 at 22:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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