openssl: It is no longer possible to load an SM2 key based on a non-SM2 curve

In 1.1.1 SM2 would work with any curve. You just had to remember to call EVP_PKEY_set_alias_type() with your key to make sure that it is handled as SM2 and not standard EC.

However if you have a key saved in a PEM file based that is intended to be used with SM2 but is based on some non-SM2 curve then it no longer seems to be possible to load it.

For example to load an SM2 key saved in SubjectPublicKeyInfo format then you might have used PEM_read_bio_PUBKEY to load it. The result would have been an EC key that you convert to SM2 using EVP_PKEY_set_alias_type(). However since the loaded key is now a provider side key the call to EVP_PKEY_set_alias_type() fails.

I thought it would be possible to load it another way using a DECODER directly, e.g.

    dctx = OSSL_DECODER_CTX_new_for_pkey(&pkey, "PEM", "SubjectPublicKeyInfo",
                                         "SM2", 
                                         OSSL_KEYMGMT_SELECT_PUBLIC_KEY
                                         | OSSL_KEYMGMT_SELECT_ALL_PARAMETERS,
                                         NULL, NULL);

Here I am telling the decoder directly to expect an SM2 key. However this still fails. Internally it loads the key as an EC key and then fails because it was expecting SM2.

This is related to but slightly different to the issue described in #14379.

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15 (15 by maintainers)

Commits related to this issue

Clarify that you cannot load SM2 keys based on a non-SM2 curve Make it explicit in CHANGES that this is not possible. Fixes #14411 — committed to mattcaswell/openssl by mattcaswell 3 years ago
Documentation: SM2 keys can use only the SM2 curve Fixes #14411 — committed to t8m/openssl by t8m 3 years ago
Documentation: SM2 keys can use only the SM2 curve Fixes #14411 Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15875) — committed to devnexen/openssl by t8m 3 years ago

Most upvoted comments

If I’ve understood the SM2 spec correctly, an SM2 key has an SM2 curve by definition. There’s absolutely nothing else that identifies them as such, they are otherwise like any EC key, including using the same OID (id-ecPublicKey) in AlgorithmIdentifiers.

Nonetheless in 1.1.1 we allowed any curve to be used, so not doing so is a breaking change.

@mattcaswell in 1.1.1 SM2 keys on arbitrary keys were similarly “ephemeral”: on saving them to a file and reloading them you would get back an EC key, with the requirement to explicitly convert it to SM2 programmatically.

The breaking change would be that it’s the way to programmatically “cast” the EC key in a SM2 key: before it was set_alias now it’s an explicit export by the EC keymgmt paired with an explicit import by the SM2 keymgmt.

As long as we retain the option of programmatically create SM2 keys over arbitrary curves, the breaking change does not equate to a functionality loss. (and as @levitte remarked, I don’t believe there is any software in production using SM2 keys over arbitrary curves: it’s mostly a thing done for experimentation, so I believe the breaking change in getting rid of set_alias, to be replaced with some other mean of “casting” the key, won’t really be catastrophic for anyone)

romen on Mar 4, 2021

I remember we discussed this a few months ago and said we do not want to suppor SM2 keys with arbitrary curves

This could be a valid answer to this problem - but if so, it is a breaking change, we should document that change in behaviour in CHANGES.md and there should be a formal OTC vote IMO.

mattcaswell on Mar 3, 2021