(WIP) An implementation of the Chinese SM2 ECC #4793

ronaldtse · 2017-11-25T16:37:52Z

documentation is added or updated
tests are added or updated

levitte

First quick look.

levitte · 2017-11-25T22:27:24Z

test/recipes/30-test_evp_data/evppkey.txt

-Key = tmppss
-Ctrl = rsa_mgf1_md:sha1
-Result = PKEY_CTRL_ERROR
-


Uhmmm, why are you taking these away?

Merge error... will fix this...

Still not fixed, it seems

FdaSilvaYY · 2017-11-26T19:37:32Z

crypto/sm2/sm2_crypt.c

+        ASN1_SIMPLE(SM2_Ciphertext, C1y, BIGNUM),
+        ASN1_SIMPLE(SM2_Ciphertext, C3, ASN1_OCTET_STRING),
+        ASN1_SIMPLE(SM2_Ciphertext, C2,
+                        ASN1_OCTET_STRING),} ASN1_SEQUENCE_END(SM2_Ciphertext)


ASN1_SEQUENCE_END should be on his own line.

FdaSilvaYY · 2017-11-26T19:38:52Z

crypto/sm2/sm2_pmeth.c

+{
+    SM2_PKEY_CTX *dctx = ctx->data;
+    EC_GROUP *group;
+    switch (type) {


blank line after declaration

FdaSilvaYY · 2017-11-26T19:40:54Z

include/openssl/sm2.h

+                   const char *user_id, const EC_KEY *key);
+
+/*
+* SM2 signatures


/* * Multi-line comment */

FdaSilvaYY · 2017-11-26T19:44:42Z

test/sm2crypttest.c

+    if (fake_rand_bytes == NULL)
+        return saved_rand->bytes(buf, num);
+
+    for(int i = 0; i != num; ++i)


for(int i ... not compatible with the old C standard .
Build will break.
Declaration should be done outside the loop.

levitte

About error code macro generation...

Actually, there might be a choice to be made here... if SM2 is such a close relative to EC, why not put it all in crypto/ec/? That would certainly make things less confusing error macro wise. But frankly, I'm unsure what's the right choice here, and I think that might be worth a discussion.

levitte · 2017-11-27T06:46:06Z

crypto/sm2/sm2_pmeth.c

+        *siglen = ECDSA_size(ec);
+        return 1;
+    } else if (*siglen < (size_t)ECDSA_size(ec)) {
+        ECerr(EC_F_PKEY_SM2_SIGN, EC_R_BUFFER_TOO_SMALL);


This should be:

SM2err(SM2_F_PKEY_SM2_SIGN, SM2_R_BUFFER_TOO_SMALL);

levitte · 2017-11-27T06:50:23Z

include/openssl/ecerr.h

+# define EC_F_PKEY_SM2_CTRL_STR                           275
+# define EC_F_PKEY_SM2_KEYGEN                             276
+# define EC_F_PKEY_SM2_PARAMGEN                           277
+# define EC_F_PKEY_SM2_SIGN                               278


Did you add these manually? Don't, run make update instead. As it is now, 274 is already taken by EC_F_EC_PKEY_PARAM_CHECK

levitte · 2017-11-27T06:53:23Z

crypto/err/openssl.txt

+EC_F_PKEY_SM2_CTRL_STR:275:pkey_sm2_ctrl_str
+EC_F_PKEY_SM2_KEYGEN:276:pkey_sm2_keygen
+EC_F_PKEY_SM2_PARAMGEN:277:pkey_sm2_paramgen
+EC_F_PKEY_SM2_SIGN:278:pkey_sm2_sign


These look manually inserted. Please take them away and let make update do the job instead.

Besides, there's something off with these names, more on that in the code that defines them

levitte · 2017-11-27T06:55:14Z

crypto/sm2/sm2_pmeth.c

+    case EVP_PKEY_CTRL_EC_PARAMGEN_CURVE_NID:
+        group = EC_GROUP_new_by_curve_name(p1);
+        if (group == NULL) {
+            ECerr(EC_F_PKEY_SM2_CTRL, EC_R_INVALID_CURVE);


This should be:

SM2err(SM2_F_PKEY_SM2_CTRL, SM2_R_INVALID_CURVE);

levitte · 2017-11-27T06:55:41Z

crypto/sm2/sm2_pmeth.c

+        if (md_type != NID_sm3 &&
+            md_type != NID_sha256 &&
+            md_type != NID_sha512_256) {
+            ECerr(EC_F_PKEY_SM2_CTRL, EC_R_INVALID_DIGEST_TYPE);


This should be:

SM2err(SM2_F_PKEY_SM2_CTRL, SM2_R_INVALID_DIGEST_TYPE);

levitte · 2017-11-27T06:55:58Z

crypto/sm2/sm2_pmeth.c

+        if (nid == NID_undef)
+            nid = OBJ_ln2nid(value);
+        if (nid == NID_undef) {
+            ECerr(EC_F_PKEY_SM2_CTRL_STR, EC_R_INVALID_CURVE);


This should be:

SM2err(SM2_F_PKEY_SM2_CTRL_STR, SM2_R_INVALID_CURVE);

levitte · 2017-11-27T06:56:34Z

crypto/sm2/sm2_pmeth.c

+    SM2_PKEY_CTX *dctx = ctx->data;
+    int ret = 0;
+    if (dctx->gen_group == NULL) {
+        ECerr(EC_F_PKEY_SM2_PARAMGEN, EC_R_NO_PARAMETERS_SET);


This should be:

SM2err(SM2_F_PKEY_SM2_PARAMGEN, SM2_R_NO_PARAMETERS_SET);

levitte · 2017-11-27T06:57:32Z

crypto/sm2/sm2_pmeth.c

+    EC_KEY *ec = NULL;
+    SM2_PKEY_CTX *dctx = ctx->data;
+    if (ctx->pkey == NULL && dctx->gen_group == NULL) {
+        ECerr(EC_F_PKEY_SM2_KEYGEN, EC_R_NO_PARAMETERS_SET);


This should be:

SM2err(SM2_F_PKEY_SM2_KEYGEN, SM2_R_NO_PARAMETERS_SET);

levitte

Syntax issues. Basically, we've set the bar at ANSI C (that's C89 or C90 depending on who you ask... the difference is quite small between the two) for syntax. If you look att the Appveyor build, you will see it have quite a lot of issues when you try a more modern syntax, for example...

Note: I haven't picked at everything, my day is severely split up today, so expect me to get back.

... and thank you for your patience, I know this can be frustrating.

levitte · 2017-11-27T07:04:56Z

crypto/sm2/sm2_crypt.c

+int SM2_ciphertext_size(const EC_KEY *key, const EVP_MD *digest, size_t msg_len)
+{
+    return 10 + 2 * EC_field_size(EC_KEY_get0_group(key)) +
+        EVP_MD_size(digest) + msg_len;


This calculates a size_t, so SM2_ciphertext_size should return size_t.

levitte · 2017-11-27T07:06:15Z

crypto/sm2/sm2_crypt.c

+    if (EVP_DigestFinal(hash, C3, NULL) == 0)
+        goto done;
+
+    struct SM2_Ciphertext_st ctext_struct;


We require ANSI C syntax, so this definition must move up to the top of the function.

levitte · 2017-11-27T07:08:05Z

crypto/sm2/sm2_crypt.c

+    const int msg_len = sm2_ctext->C2->length;
+    uint8_t msg_mask[msg_len];
+
+    const uint8_t *C3 = sm2_ctext->C3->data;


ANSI C syntax. These definitions must move above the memset line.

levitte · 2017-11-27T07:09:19Z

crypto/sm2/sm2_crypt.c

+    if (sm2_ctext->C3->length != hash_size)
+        goto done;
+
+    EVP_MD_CTX *hash = EVP_MD_CTX_new();


ANSI C syntax. This must move above the memset line. Besides, this becomes a memory leak, as it isn't freed in the done section...

levitte · 2017-11-27T07:11:13Z

crypto/sm2/sm2_crypt.c

+    EC_POINT *kG = EC_POINT_new(group);
+    EC_POINT *kP = EC_POINT_new(group);
+    const EC_POINT *P = EC_KEY_get0_public_key(key);
+    uint8_t msg_mask[msg_len];


ANSI C requires a constant expression for the size. You may need to allocate msg_mask on the heap

levitte · 2017-11-27T07:11:37Z

crypto/sm2/sm2_crypt.c

+    const size_t field_size = EC_field_size(group);
+    uint8_t x2y2[2 * field_size];
+    uint8_t x2_bits[field_size];
+    uint8_t y2_bits[field_size];


ANSI C needs constant expressions...

levitte · 2017-11-27T07:11:55Z

crypto/sm2/sm2_crypt.c

+    uint8_t y2_bits[field_size];
+
+    const size_t C3_size = EVP_MD_size(digest);
+    uint8_t C3[C3_size];


Constant expression...

levitte · 2017-11-27T07:13:32Z

crypto/sm2/sm2_crypt.c

+    const size_t field_size = EC_field_size(group);
+    uint8_t x2y2[2 * field_size];
+    uint8_t x2_bits[field_size];
+    uint8_t y2_bits[field_size];


Constant expressions

levitte · 2017-11-27T07:13:46Z

crypto/sm2/sm2_crypt.c

+    BIGNUM *x2 = BN_new();
+    BIGNUM *y2 = BN_new();
+    const size_t hash_size = EVP_MD_size(digest);
+    uint8_t computed_C3[hash_size];


Constant expression

levitte · 2017-11-27T07:14:05Z

crypto/sm2/sm2_crypt.c

+
+    const uint8_t *C2 = sm2_ctext->C2->data;
+    const int msg_len = sm2_ctext->C2->length;
+    uint8_t msg_mask[msg_len];


Constant expression...

stevelinsell · 2017-12-07T00:01:09Z

crypto/sm2/sm2_crypt.c

+                size_t msg_len, uint8_t *ciphertext_buf, size_t *ciphertext_len)
+{
+    int rc = 0;
+    BIGNUM *k = BN_new();


Any reason for not creating the ctx first then using BN_CTX_start() and then allocating k, x1, y1, x2, y2 using BN_CTX_get() to make the cleanup simpler. At the moment you seem to just be creating the ctx to pass down to other functions but don't use it in this function. You'd have to declare the variables first in that case, before assigning to them after starting the ctx.

stevelinsell · 2017-12-07T00:06:14Z

crypto/sm2/sm2_crypt.c

+    BIGNUM *x2 = BN_new();
+    BIGNUM *y2 = BN_new();
+
+    BN_CTX *ctx = BN_CTX_new();


Code needs to be a little more defensive, no checking for BN_CTX_new() returning NULL

stevelinsell · 2017-12-07T00:07:47Z

crypto/sm2/sm2_crypt.c

+    BIGNUM *x1 = BN_new();
+    BIGNUM *y1 = BN_new();
+    BIGNUM *x2 = BN_new();
+    BIGNUM *y2 = BN_new();


Currently these also all need checking for NULL, if you move to allocate from the ctx then you only need to check the last allocation

stevelinsell · 2017-12-07T00:10:14Z

crypto/sm2/sm2_crypt.c

+    const EC_GROUP *group = EC_KEY_get0_group(key);
+    const BIGNUM *order = EC_GROUP_get0_order(group);
+    EC_POINT *kG = EC_POINT_new(group);
+    EC_POINT *kP = EC_POINT_new(group);


Again need to be a little more defensive these EC_POINT_new() calls could return NULL but there is no checking.

stevelinsell · 2017-12-07T00:12:00Z

crypto/sm2/sm2_crypt.c

+    BIGNUM *y2 = BN_new();
+
+    BN_CTX *ctx = BN_CTX_new();
+    EVP_MD_CTX *hash = EVP_MD_CTX_new();


I'm guessing this one also needs a check for NULL too.

stevelinsell · 2017-12-07T00:17:01Z

crypto/sm2/sm2_crypt.c

+    memcpy(x2y2, x2_bits, field_size);
+    memcpy(x2y2 + field_size, y2_bits, field_size);
+
+    // This happens to match the KDF used in SM2


C++ style comment violates OpenSSL coding style document

stevelinsell · 2017-12-07T00:22:05Z

crypto/sm2/sm2_crypt.c

+    uint8_t x2_bits[field_size];
+    uint8_t y2_bits[field_size];
+    BIGNUM *x2 = BN_new();
+    BIGNUM *y2 = BN_new();


Same comment here about starting and allocating from the ctx for these bignums.
Again same comments in this function about checking for NULL's from allocations.

stevelinsell · 2017-12-07T00:43:49Z

crypto/sm2/sm2_pmeth.c

+    if(der_sig == NULL)
+       return 0;
+
+    // Now ASN.1 encode ...


Wrong style of comment

stevelinsell · 2017-12-07T00:52:03Z

crypto/sm2/sm2_pmeth.c

+    } else if(strcmp(type, "user_id") == 0) {
+        SM2_PKEY_CTX *dctx = ctx->data;
+        free(dctx->user_id);
+        dctx->user_id = OPENSSL_strdup(value);


Is it intentional to drop out of this else after assigning the user_id and return -2. Surely you only want to return -2 on a failure case?

stevelinsell · 2017-12-07T00:57:50Z

crypto/sm2/sm2_pmeth.c

+        return 0;
+    }
+    ec = EC_KEY_new();
+    if (!ec)


Consistency, at line 202 you check (ec == NULL), here you check (!ec) after the same type of allocation. Better to be consistent and stick to (ec == NULL).

stevelinsell · 2017-12-07T01:07:00Z

crypto/sm2/sm2_sign.c

+                                const char *user_id,
+                                const uint8_t *msg, size_t msg_len)
+{
+    EVP_MD_CTX *hash = EVP_MD_CTX_new();


Check for NULL if allocation fails.

stevelinsell · 2017-12-07T01:07:27Z

crypto/sm2/sm2_sign.c

+    if (EVP_DigestUpdate(hash, msg, msg_len) == 0)
+        goto done;
+
+    // reuse za buffer to hold H(ZA || M)


Again change comment style

stevelinsell · 2017-12-07T01:11:58Z

crypto/sm2/sm2_sign.c

+{
+    EVP_MD_CTX *hash = EVP_MD_CTX_new();
+    const int md_size = EVP_MD_size(digest);
+    uint8_t za[md_size];


Another variable that probably needs allocating on the heap to avoid ANSI C violation.

stevelinsell · 2017-12-07T01:17:52Z

crypto/sm2/sm2_sign.c

+    BIGNUM *s = BN_new();
+    BIGNUM *x1 = BN_new();
+    BIGNUM *tmp = BN_new();
+    BN_CTX *ctx = BN_CTX_new();


Again why not move the ctx declaration higher and use the ctx for some of these BIGNUM allocations, the ones that are only in scope within this function, ie. k, x1 and tmp

stevelinsell · 2017-12-07T01:18:59Z

crypto/sm2/sm2_sign.c

+    const BIGNUM *dA = EC_KEY_get0_private_key(key);
+    const EC_GROUP *group = EC_KEY_get0_group(key);
+    const BIGNUM *order = EC_GROUP_get0_order(group);
+    EC_POINT *kG = EC_POINT_new(group);


Again a bit more checking of allocation failures required.

stevelinsell · 2017-12-07T01:19:40Z

crypto/sm2/sm2_sign.c

+        if (BN_mod_add(r, e, x1, order, ctx) == 0)
+            goto done;
+
+        // try again if r == 0 or r+k == n


Wrong comment style again

stevelinsell · 2017-12-07T01:25:27Z

crypto/sm2/sm2_sign.c

+
+        BN_mod_mul(s, s, tmp, order, ctx);
+
+        sig = ECDSA_SIG_new();


This allocation could fail and needs to be checked for NULL

stevelinsell · 2017-12-07T01:51:49Z

crypto/sm2/sm2_crypt.c

+        == 0)
+        goto done;
+
+    for (size_t i = 0; i != msg_len; ++i)


Declare variable at top outside of loop.

stevelinsell · 2017-12-07T01:53:32Z

crypto/sm2/sm2_crypt.c

+        == 0)
+        goto done;
+
+    for (size_t i = 0; i != msg_len; ++i)


Again declare variable at top outside of loop

stevelinsell · 2017-12-07T10:40:43Z

crypto/sm2/sm2_crypt.c

+    /* Is there some simpler way to do this? */
+    BIGNUM *p = BN_new();
+    BIGNUM *a = BN_new();
+    BIGNUM *b = BN_new();


Should check all of these allocations for NULL, or use a BN_CTX and check the last allocation.

stevelinsell · 2017-12-07T10:49:22Z

crypto/sm2/sm2_za.c

+
+    const EC_GROUP *group = EC_KEY_get0_group(key);
+
+    BN_CTX *ctx = NULL;         // ???


This seems pointless at the moment, you're just using it to pass a NULL parameter to EC_GROUP_get_curve_GFp() and EC_POINT_get_affine_coordinates_GFp(). You might as well either pass NULL directly to the functions without a variable if you want them to handle creating the BN_CTX or you should call BN_CTX_new() and BN_CTX_free() within this function and pass a valid pointer to the functions. The later will be more efficient than the current implementation as you'll only be doing a single BN_CTX_new()/BN_CTX_free() rather than 3.

stevelinsell · 2017-12-07T11:00:46Z

crypto/sm2/sm2_za.c

+       ZA=H256(ENTLA || IDA || a || b || xG || yG || xA || yA)
+     */
+
+    size_t uid_len = strlen(user_id);


More declarations of variables in the middle of a code block, several below as well, the declarations need to move to the top.

stevelinsell · 2017-12-07T12:49:22Z

test/sm2crypttest.c

+   {
+   BIGNUM* p = NULL;
+   BN_hex2bn(&p, p_hex);
+   BIGNUM* a = NULL;


All the test code suffers from the same issues as already noted in the main files and needs sorting:

Variables declared in the middle of code blocks.
Variables declared based on sizes unknown at compile time (allocate dynamically)
Incorrect style of some comments.

I won't flag them individually.

levitte · 2017-12-15T11:14:09Z

Hey @ronaldtse, is something happening here? It's been very silent lately...

ronaldtse · 2017-12-15T14:49:12Z

Sorry guys got caught up in finishing up work before the holidays -- will try to finish this by the end of year 😉

levitte

I just read through this PR as it currently stands, and it looks fine as it currently stands. The only thing that still stings the eye a bit is the set of public SM2 functions. However, I'm also concerned about the beta cycle starting tomorrow, so everything considered, I think it's better this gets into 1.1.1-dev now, and the public SM2 functions can be removed within the beta cycle, rather than not having this in 1.1.1 at all.

levitte · 2018-03-19T13:16:45Z

FYI, the conflicts with master are all about make update, and are therefore easy to resolve. I tried it moments ago, it took me 5 minutes, something I can live with ;-)

levitte · 2018-03-19T13:17:21Z

@levitte will you merge?

Sure. I already have the merge lined up, so ;-)

mattcaswell · 2018-03-19T13:27:03Z

Please raise an issue if there is something about this that needs to be fixed post-merge.

levitte · 2018-03-19T13:28:44Z

Will do

levitte · 2018-03-19T13:29:49Z

Also, apologies to @ronaldtse, @randombit and @InfoHunter for letting this one hanging for so long...

levitte · 2018-03-19T13:34:36Z

Merged.

4e66475 Handle evp_tests assumption of EVP_PKEY_FLAG_AUTOARGLEN
dceb99a Support SM2 ECIES scheme via EVP
3d328a4 Add SM2 signature and ECIES schemes

Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #4793)

Without actually using EVP_PKEY_FLAG_AUTOARGLEN Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #4793)

dot-asm · 2018-03-19T14:06:02Z

util/libcrypto.num

+SM2_compute_userid_digest               4452	1_1_1	EXIST::FUNCTION:
+SM2_verify                              4453	1_1_1	EXIST::FUNCTION:
+SM2_sign                                4454	1_1_1	EXIST::FUNCTION:
+ERR_load_SM2_strings                    4455	1_1_1	EXIST::FUNCTION:


Do these actually have to be exported? And if actually so, does it mean that no-sm2 wouldn't work? And it seems that it doesn't. I mean attempt to configure with no-sm2 fails. Is it actually intentional?

ronaldtse · 2018-03-20T02:17:59Z

Thanks @richsalz @levitte for merging!

guanzhi · 2018-04-08T13:38:28Z

The behavior of ec_pkey_meth should not behave differently depends on which curve is used. The current design takes the SM2 curve a special condition, when the SM2 curve is used, the ec_pkey_meth use a set of different algorithms. This means

Application will not know that the default ECDSA algorithm is not used if SM2 is not disabled.
Application can not use curves like secp256k1 with SM2 sign/verify, and the SM2 users can only use the recommended SM2 curve with SM2 sign/verify, encrypt/decrypt. From the SM2 related standards, the recommend curve is only a recommended curve, but not the only curve should be supported. There are 192-bit and binary curves in the SM2 test vectors. And there might be future more secure (512-bit) recommended curve, and there might be application specified curves which need to work with the EVP API and SM2 sign/verify/encrypt/decrypt.

guanzhi · 2018-04-08T13:46:03Z

It is very nature that the same EC_KEY can support different sign/encrypt algorithms such as SECG standards, China SM2 standards, Korea Standards, or some others such as Schnorr signature. The users have the right to use any combination of these algorithms and curves builtin or specified. As a solution, the GmSSL use EVP_PKEY_CTX_ctrl to let the caller explicitly select which algorithm he/she want to use,
and it is similar as RSA or ciphers, that users can use ctrl to set the behavior.

guanzhi · 2018-04-08T13:56:12Z

When signing message M, the SM2 sign the digest of Z||M. Although EVP_SignInit/Update/Final can not support this behavior, the EVP_DigestSignInit/Update/Final can. As the signer's EVP_PKEY is given to EVP_DigestSignInit.

Is the current implementation of EVP support this behavior (Z value is digest updated before message M) ?

levitte · 2018-04-09T13:25:57Z

Hmmm... when I initially started reviewing this, I was under the distinct impression that the SM2 algo was tightly coupled with the SM2 specific curves, and the responses I got didn't give me any other impression.

randombit · 2018-04-09T14:06:51Z

Personally I was unaware of any additional curve support in SM2.

Re splitting out the PKEY, this would probably make more sense given the above comments. I initially did create the PR with a distinct SM2 PKEY but it seemed a needless complication (see comments in early January).

ronaldtse · 2018-04-09T14:35:39Z

According to GB/T 32918.5-2017 (the fifth part of the SM2 Standard), the implemented curve is no longer a "recommended curve" (which it was previously called), but it is "the" official curve. Therefore nothing further needs to be done for GB/T 32918 (SM2 Standard) compliance.

That said, it is true that in GB/T 32915.{2,3,4} some examples provided are calculated over different curves, so for generality and flexibility reasons it would be beneficial to support such change. But I would consider it optional.

mattcaswell · 2018-04-10T08:26:24Z

I've not studied this in detail but from the comments I've seen here it seems to make sense to have a different pkey type. I'd rather make sure we have the correct solution rather than support something a bit quirky and not quite right for ever more. If we're going to do do it, we'd better get on with it.

levitte · 2018-04-10T10:45:36Z

Could someone please create an issue instead of discussing in a closed PR? (the discussion thread is too big anyway, causes github not to want to load it at times)

ronaldtse · 2018-04-10T15:05:24Z

@levitte extracted to new issue: #5924

Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from openssl/openssl#4793)

levitte requested changes Nov 25, 2017

View reviewed changes

FdaSilvaYY reviewed Nov 26, 2017

View reviewed changes

levitte requested changes Nov 27, 2017

View reviewed changes

stevelinsell reviewed Dec 7, 2017

View reviewed changes

crypto/sm2/sm2_pmeth.c Outdated

if(der_sig == NULL)

return 0;

// Now ASN.1 encode ...

Copy link

Contributor

stevelinsell Dec 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrong style of comment

stevelinsell reviewed Dec 7, 2017

View reviewed changes

levitte approved these changes Mar 19, 2018

View reviewed changes

levitte closed this Mar 19, 2018

levitte pushed a commit that referenced this pull request Mar 19, 2018

Add SM2 signature and ECIES schemes

3d328a4

Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #4793)

levitte pushed a commit that referenced this pull request Mar 19, 2018

Support SM2 ECIES scheme via EVP

dceb99a

Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #4793)

levitte mentioned this pull request Mar 19, 2018

Make public SM2 functions libcrypto private #5670

Closed

dot-asm reviewed Mar 19, 2018

View reviewed changes

liuqun mentioned this pull request Apr 8, 2018

OpenSSL 1.1.1预览版已经开始支持SM2/SM3/SM4算法 guanzhi/GmSSL#468

Closed

dot-asm mentioned this pull request Apr 8, 2018

Make SM2 functions private #5895

Closed

ronaldtse mentioned this pull request Apr 10, 2018

Refactor SM2 implementation to use its own PMETH #5924

Closed

busterb pushed a commit to libressl/fuzz that referenced this pull request Jan 23, 2019

Add SM2 signature and ECIES schemes

8744ae6

Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from openssl/openssl#4793)

Yikun mentioned this pull request Jul 17, 2020

SM2/SM3/SM4 algorithm support for ssl protocol #12473

Open

thedreamwork mentioned this pull request Jul 25, 2022

Add SM2 Digital Signature Algorithm Support w3c/webauthn#1783

Closed

azasypkin mentioned this pull request Jan 1, 2024

Add support for SM2, SM3 and SM4 secutils-dev/secutils#40

Open


		const EC_GROUP *group = EC_KEY_get0_group(key);

		BN_CTX *ctx = NULL; // ???

(WIP) An implementation of the Chinese SM2 ECC #4793

(WIP) An implementation of the Chinese SM2 ECC #4793

Conversation

ronaldtse commented Nov 25, 2017

levitte left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

levitte left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

levitte left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

levitte commented Dec 15, 2017

ronaldtse commented Dec 15, 2017

levitte left a comment

Choose a reason for hiding this comment

levitte commented Mar 19, 2018

levitte commented Mar 19, 2018

mattcaswell commented Mar 19, 2018

levitte commented Mar 19, 2018

levitte commented Mar 19, 2018

levitte commented Mar 19, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ronaldtse commented Mar 20, 2018

guanzhi commented Apr 8, 2018

guanzhi commented Apr 8, 2018

guanzhi commented Apr 8, 2018

levitte commented Apr 9, 2018