lua-resty-crypto
lua-resty-crypto copied to clipboard
toruneko
关于国密sm2加密结果转16进制后非04开头
尝试sm2加解密，lua使用加解密正常，但是尝试解密其他语言加密结果时，无法解密。 转16进制后发现，lua加密结果类似为306D022100B7C48862904141DC17DA225CDF30BEF83113D4C151DF2FCB517875FC6FC7F58E02207E7AA760DB6572CDFC091EA39D4A2A9CF833E772C99CA87D793322101B9FB6490420F7ABF531C709C9EBB5CB7A8172D07A0F29849AC6829B620FE25D2E9215A6FDF00404C13DC00C 查看sm2国密文档，16进制国密sm2结果基本为04开头的串，请问是哪用错了吗？
resty -e 'local resty_sm2 = require "resty.sm2" local resty_str = require "resty.string" -- generator an eckey local pubkey, prvkey = resty_sm2.generate_key() -- new instance with sm3 hash algorithm -- will be sign and decrypt mode when private key set. local data = "test"
-- will be verify and encrypt mode when private key not key local sm2, _ = resty_sm2.new({ public_key = pubkey, algorithm = "sm3", id = "[email protected]" }) local enc = sm2:encrypt(data) ngx.say(string.upper(resty_str.to_hex(enc)))
local sm2, _ = resty_sm2.new({ private_key = prvkey, public_key = pubkey, algorithm = "sm3", id = "[email protected]" }) sm2:decrypt(enc)'
openresty版本nginx version: openresty/1.15.8.1编译的openssl为built with OpenSSL 1.1.1c
OpenSSL 1.1.1开始支持了SM2，但是在文档中仅提到关于签名的用法。可能并不支持加密与解密，而且本身非对称算法仅适用小字符串的加解密。
至于你提到的问题，SM2加解密我也没有仔细的研究过。你可以尝试一下签名/验签，如果和Java或其他语言可以互相正确验签，那加解密这块确实不支持，或者需要再深入研究。
https://www.openssl.org/docs/man1.1.1/man7/SM2.html
一直忘记回复这个事情了，SM2加解密也是支持的，加密结果306D022100B7C48862904141DC17DA225CDF30BEF83113D4C151DF2FCB517875FC6FC7F58E02207E7AA760DB6572CDFC091EA39D4A2A9CF833E772C99CA87D793322101B9FB6490420F7ABF531C709C9EBB5CB7A8172D07A0F29849AC6829B620FE25D2E9215A6FDF00404C13DC00C 其实是国际规范asn.1的编码格式，这个应该是DER编码，可以如下解码 30（tag） 6D（length） 02（tag） 21（length） 00(填充) B7C48862904141DC17DA225CDF30BEF83113D4C151DF2FCB517875FC6FC7F58E 02（tag）20 （length） 7E7AA760DB6572CDFC091EA39D4A2A9CF833E772C99CA87D793322101B9FB649 04（tag）20 （length） F7ABF531C709C9EBB5CB7A8172D07A0F29849AC6829B620FE25D2E9215A6FDF0 04（tag）04（length） C13DC00C
如此得到 C1X:B7C48862904141DC17DA225CDF30BEF83113D4C151DF2FCB517875FC6FC7F58E C1Y:7E7AA760DB6572CDFC091EA39D4A2A9CF833E772C99CA87D793322101B9FB649 C3:F7ABF531C709C9EBB5CB7A8172D07A0F29849AC6829B620FE25D2E9215A6FDF0 C2:C13DC00C
解码后密文在头部加上04
04B7C48862904141DC17DA225CDF30BEF83113D4C151DF2FCB517875FC6FC7F58E7E7AA760DB6572CDFC091EA39D4A2A9CF833E772C99CA87D793322101B9FB649F7ABF531C709C9EBB5CB7A8172D07A0F29849AC6829B620FE25D2E9215A6FDF0C13DC00C 上面的密文就可以在其他端解密了
不过目前生产使用这么久发现了另一个问题，openssl加密结果C1X,C1Y的长度可能小于32字节，这种情况在其他端解密会失败。可以参考这个openssl的漏洞https://xie.infoq.cn/article/9685264098848c3024593c629 该漏洞修复后只是解决了解密内存泄露的问题，加密时C1X,C1Y的长度可能小于32字节并未避免。
