关于SM2算法 ASN.1编码 - 签名长度

最新推荐文章于 2025-04-20 00:05:36 发布
原创 最新推荐文章于 2025-04-20 00:05:36 发布 · 5.1k 阅读 · 44 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#密码学

本文详细解释了SM2算法签名在编码过程中可能出现的特殊情况，包括正常长度、特殊情况下的字节数，以及前导0在编码时的处理规则，提醒开发者在解析和编码时需注意这些细节。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

写这篇文章是为了在SM2签名编码解析上少走弯路，签名长度会超出我们预期的不同。

一、常规理解

       SM2算法正常不做编码的签名长度为64个字节，即 R + S，各32个字节；

        即使经过了ASN.1 DER编码，通常理解签名长度只有3种可能性，即：70字节、71字节、72个字节，分别对应：

        70个字节： 3044 + 02 20 + 32个字节R + 02 20 + 32个字节S 

       如果R和S的第一个字节的最高位为1时，需要分别前导补0，即产生71个字节和72个字节编码

        71个字节：3045 + 02 21 00 + 32个字节R + 02 20 + 32个字节S

                           3045 + 02 20 + 32个字节R + 02 21 00 + 32个字节S

        72个字节： 3046 + 02 21 00 + 32个字节R + 02 21 00 + 32个字节S

 二、实际存在的情况             

在ANS.1 编码中，有以下几种特殊情况存储：

（1）69个字节

情形1：

3043
021F
2DF69838E2E40DE378C9B8A2FD40FB87425AF4DB9297B9337A9B6586CBFAF3
0220
67301CAC496D878723EC946F570922A3D84A6B8D2E618C6AD907E36B13D4833F:

情形2：

3043
0220
53EB989118AD14E1CA91A93769CCE234079169A94BFF645240D7DF59FFEF8B5E
021F
3B27E6F7849714C6A8EFD43C9E8045BA9B01477C7ADC3C7AFDF8056EBE05CF

如果R或S的数据存在前导0时，在实际编码过码中，会删掉前导00的长度。

如上是1F，表明第一个字节为00

（2）70个字节

情形1：

3044
021F
638026332E9FCD750647AFCFC2A5CFD3639D5BF1C9D619F23740241257FD3C
022100
9862D169D9F5BDA16848DB5D1BEDE5A616914680B6CADF1AE373A3D03D365ACF

情形2：

3044
022100
E92A4B5821120820CE2F45DFD58C07B9F1D69C7483009ADA9206678661FC5A65
021F
1DBED6061F0AAEFB3B444EBA2361E0B28A1EB5D8AC789F5D218DA8A8616E2F

情形3：（特别注意）

3044
0220
36A245F75927E7B8B09C9827F92B3913117771679B70838273BA547751778FC5
0220
00B1E4BCF9FF3ABADC596936FFBA0CA59C1A0E812DD7F5A9BEDC36863C11D119

3044
0220
0A7BF6655422E053B7E2D4C5609ED88DD98DC7B52A618A6474D01F86FE2B5614
0220
0084D6C1A052FA6FBCA036EDFACFEBBAB90A53442C3DCEA748AABCD41E7E1C91

特别注意这个数据，S数据存在00，但实际编码长度时，并未删除。

针对以上现象，需要注意的是，R或S数据中存在前导0时，是否删除，取决于其后一个字节，是否存在补位（即第一个字节最高位是否为1），从上面数据可知：

021F2D、021F1D、021F3B、021F63删除了前导0

022000B1、02200084 保留了前导0

均符合了上面的规律，因此在数据解析和编码时，要特别注意。

softt
关注
SM2加密的密文byte数组与ASN.1互转
M先生的博客
07-01 692
SM2加密的字节数组转换为ASN.1结构对象
基于OpenSSL，实现SM2签名数据的ASN1编码转换
weixin_49984575的博客
08-27 2590
在实际应用场景中会遇到ASN1数据的编码转换，如，在硬件密码库中使用的API接口和在OpenSSL中使用的接口，很有可能是两种格式数据的表现形式，因此，本文提供以下方式进行数据格式的转换。
[密码学实战]Java 实现 SM2 国密算法（签名带id、验签及 C1C3C2 加密解密）
曼岛_的博客
02-26 2600
[密码学实战]Java实现SM2国密算法：签名带id及不带id、验签、加密(c1c3c2)与解密
使用SM2密钥对签名验签(ArkTS)
最新发布
RZer的博客
04-20 439
调用cryptoFramework.createVerify，指定字符串参数’SM2_256|SM3’，创建非对称密钥类型为SM2_256、摘要算法为SM3的Verify实例，用于完成验签操作。调用cryptoFramework.createSign，指定字符串参数’SM2_256|SM3’，创建非对称密钥类型为SM2_256、摘要算法为SM3的Sign实例，用于完成签名操作。调用Sign.update，传入待签名的数据。对应的算法规格请查看签名验签算法规格：SM2。调用Sign.sign，生成数据签名。
由asn1编码引发对sm2签名长度思考
zmnbehappy的博客
03-21 1万+
起因 工作相关的朋友咨询我sm2签名长度的问题，故有了这篇文章。 过程 问：按照国密规范，签名长度64，为什么长度可变？ 答：要按这个假设，应该的范围是68，69，70，71，72。 最好是按asn1解析 问：我刚才看了下GM/T 0003.2中的规定，看上去签名结果就应该是(r,s)的字符串形式64个字节的，我后来看了下这个文档的附录A中的两个用例，签名的结果都是r:32字节 s:32...
SM2签名长度分析
weixin_38700215的博客
11-26 855
三种不同长度区别在于R或者S有一个前导00，为什么？因为R和S值都是一个32字节整数，如果这一整数最高位为1(如果最高位为1即首字节大于127)，则有可能被认为是负数，为了保证不被解析为负数，在从32字节的R和S变换为ASN.1格式的DER编码的时候人为的增加了一个前导00做最高位，这也就导致了前面的表示长度部分由20变21，以及由44变45或46
SM2数字签名结果的分析，本应64字节，为啥有工具显示70字节、71字节、72个字节三种结果
baikeley74的博客
03-22 4056
密评中签名结果判断第一个字节应该是。
为什么SM2算法签名结果不是64字节？
CrazyFlyingBee的博客
10-18 793
为什么SM2算法签名结果不是64字节？
hutool国密sm2算法使用， 正确的秘钥生成签名及验签，签名为64字节
热门推荐
qq_33140565的博客
02-15 3万+
hutool工具类： 在糊涂提供的国密算法，需要通过椭圆曲线生成秘钥，且当前业内私钥长度为固定32字节，公用固定长度为64字节。在参考hutool官方文档中的国密算法的例子，发现生成的秘钥非常长，远大于32字节和64字节，生成的签名长度也不是64字节。 问题描述： 官方提供如下例子，用于演示签名和验签 String content = "我是Hanley."; KeyPair pair = SecureUtil.generateKeyPair("SM2"); final SM2 sm2 = new SM2(
GB35114---聊聊SM2签名格式
xlb8224866的博客
03-17 1万+
公司原计划是年后让我直接去公安一所过35114的认证，但是突发疫情，导致上班时间一推再推，最后也只能远程用升级包的方式给检测员进行认证。 前几次的尝试，服务器一直回复401，让我百思不得其解，甚至开始让我产生对算法的怀疑。现在回过头来看，其实SM2签名格式不理解是导致一直验签失败的主要原因。 按照国密的规范，SM2签名结果r||s长度应该是(r:32字节)+(s:32字节)64字节，就算加个0...
Java 算法SM2加密解密
码上梦醒码上仙
09-27 1万+
简介 什么是SM2 SM2是国家密码管理局于2010年12月17日发布的椭圆曲线公钥密码算法。 SM2 算法和 RSA 算法都是公钥密码算法，SM2 算法是一种更先进安全的算法，在我们国家商用密码体系中被用来替换 RSA 算法。 随着密码技术和计算机技术的发展，目前常用的 1024 位 RSA 算法面临严重的安全威胁，我们国家密码管理部门经过研究，决定采用 SM2 椭圆曲线算法替换RSA算法。 SM2算法和RSA算法比较 SM2性能更优更安全：密码复杂度高、处理速度快、机器性能消耗更小 - SM
SM2签名算法规范
04-14
国密SM2椭圆曲线公钥密码算法规范中签名算法部分，有利于理解并使用
SM2加密算法签名（超全，亲测可用）
12-27
SM2加密算法签名（超全，亲测可用),需要依赖包，maven项目可以在pom.xml中引入 org.bouncycastle bcprov-jdk15on 1.54
RSA加密解密签名(密钥任意长度)
10-09
java通用加密解密。安卓通用必须要另外下载包。注意必须GBK字符集转换。
C语言实现的SM2数字签名验证
07-15
在goldboar写的SM2签名及验签函数（ http://download.csdn.net/detail/goldboar/3833072）的基础上，改写的一个纯粹用来做SM2签名验证的函数，编译时需要用到OpenSSL的头文件和库文件（libeay32.lib或libeay32.dll），与goldboar的程序区别如下： 1.仅用于做验签，不能签名； 2.验签使用外部传入的SM2公钥，SM2公钥以(x,y)坐标形式传入； 3.签名也是以(r,s)坐标形式传入； 4.增加了一些内存清理语句，内存泄漏有改善； 5.goldboar的程序中使用的ECC参数是示例参数，不是GM/T 0003.5-2012规范中定义的参数，这里的验签函数中采用的是规范中定义的参数。 6.将一些对椭圆曲线参数的验证操作放入 _DEBUG 宏限制的范围内。因为参数是规范推荐的，已经过验证，所以在程序中无需再验证。将这些验证语句放入 _DEBUG 宏限制的范围内以后，如果编译 release 版本时就不会包含这些验证语句，效率可以有一点提升。
关于SM2算法 ASN.1编码 踩过的坑 - 加密
softt的博客
12-01 1927
在某些项目开发过程中，或多或少很多底层安全OS系统或者算法库，都引入了openssl或者gmssl的一些内容来实现算法，这样就导致算法运算结果并不是完全按照国密标准的裸数据，而是经过编码之后的数据，编码之间的对齐对上层业务系统互通带来的一些挑战。经过分析发现，C1y的数据也是对的，原因是C1y丢失的那个字节是为0，不计算在长度里面，在实际系统中，需要进行补0 操作。C1y的长度不一样，正常为32个字节，不正常的为31个字节，如果直接取数据会导致业务异常。
ASN.1编码方式详解
weixin_30567471的博客
11-13 1097
ASN ASN.1 – Abstract Syntax Notation dot one，抽象记法1。数字1被ISO加在ASN的后边，是为了保持ASN的开放性，可以让以后功能更加强大的ASN被命名为ASN.2等，但至今也没有出现。 描述了一种对数据进行表示、编码、传输和解码的数据格式。它提供了一整套正规的格式用于描述对象的结构，而不管语言上如何执行及这些数据的具体指代，也不用去管到底是什么样的应用...
SM2的签名值byte数组与ASN.1互转
M先生的博客
07-01 625
ASN.1抽象语言标记（Abstract Syntax Notation One） ASN.1是一种 ISO/ITU-T 标准，描述了一种对数据进行表示、编码、传输和解码的，它提供了一整套正规的格式用于描述对象的结构。
国密算法签名与加密结果字节长度变化及Hex与Base64编码长度变化
m0_61869253的博客
03-02 1634
有很多应用场景，数据通常经过加密和编码后传输，有时我们需要知道经过处理后的数据的长度，此时就需要分析各种算法的数据处理策略，及结果变化。下边主要介绍国密SM2算法签名与加密结果字节长度变化及Hex与Base64编码长度变化。
sm2 加密 c1c2c3 python
04-18
<think>好的，我需要帮助用户在Python中实现SM2加密算法，并处理c1c2c3格式的密文。首先，我得回顾一下用户提供的引用内容，特别是引用[1]、[2]、[3]、[4]中的相关信息。 根据引用[1]，用户之前可能接触过国密算法，如SM3和SM4，但这次是SM2。引用[2]提到SM2包括数字签名、密钥交换和加密，这里用户需要的是加密部分。引用[3]详细说明了SM2加密后的密文结构为C1C3C2，即65字节的公钥部分、32字节的摘要和明文长度的密文。而不同语言之间的问题通常是因为ASN.1编码，但用户明确要求生成c1c2c3格式，可能需要避免ASN.1，直接处理原始数据。引用[4]展示了一个Golang的例子，其中提到了C1C2C3的排列方式，可能需要在Python中模仿。 首先，用户想在Python中实现SM2加密，生成C1C2C3格式。我需要考虑现有的库。gmssl库的sm2模块可能是一个起点，但根据引用[1]中的示例，gmssl的sm3_hash被使用，但sm2的加密可能默认使用ASN.1编码，而用户需要原始C1C2C3格式。 查看gmssl的文档，sm2.Encrypt函数可能默认返回ASN.1编码的密文，而不是C1C2C3的拼接。例如，引用[3]指出，OpenSSL使用ASN.1编码，而用户需要的是原始数据。因此，可能需要自定义处理，将各部分拼接成C1C3C2或C1C2C3的顺序。 根据引用[3]，SM2密文结构为C1 || C3 || C2，其中C1是65字节（0x04开头，x和y各32字节），C3是32字节的摘要，C2是明文长度的密文。但引用[4]中的Golang代码使用了sm2.C1C2C3作为参数，可能表示不同的顺序。这里可能存在混淆，需要确认正确的顺序。 需要查阅SM2标准，确认密文结构。根据《SM3密码杂凑算法》相关文档，SM2加密后的密文应该是C1C3C2，即公钥点、SM3摘要、加密后的密文。但不同实现可能有差异，比如有的可能使用C1C2C3。例如，gmssl库的sm2.Encrypt函数可能有一个参数来指定模式，如引用[4]中的sm2.C1C2C3，这可能导致不同的拼接顺序。 因此，可能的解决方案是使用gmssl库，并在加密时指定模式为C1C2C3，然后手动拼接各部分。或者，如果库返回的是ASN.1编码的数据，则需要解析ASN.1结构，提取各部分并按正确顺序拼接。 接下来，我需要检查gmssl的sm2.Encrypt函数的参数。根据引用[4]，Golang中的sm2.Encrypt接受一个模式参数，如sm2.C1C2C3。那么在Python的gmssl库中是否有类似的参数？假设存在，那么在Python中调用时指定该模式，可能直接得到正确格式的密文。 假设gmssl的sm2.Encrypt函数返回的是原始拼接的密文，而不是ASN.1编码，那么直接处理即可。但根据引用[3]，如果使用OpenSSL或其他库，可能需要处理ASN.1编码，但用户希望避免这种情况，直接生成C1C2C3格式。 另外，用户提供的引用[4]中的Golang代码示例中，加密后的字符串是通过拼接C1C2C3得到的。所以可能需要类似地在Python中处理。 可能的实现步骤： 1. 生成SM2密钥对。使用gmssl的sm2模块生成私钥和公钥。 2. 使用公钥加密明文，指定模式为C1C2C3，得到密文的字节流。 3. 验证密文结构是否为C1 || C2 || C3，或者C1 || C3 || C2，根据库的实现调整。 4. 如果库返回的是ASN.1编码，需要解析并提取各部分，再按正确顺序拼接。 但首先，需要确认gmssl库的sm2.Encrypt函数是否支持指定输出格式。查阅gmssl的文档或源代码，发现sm2.Encrypt可能有参数来控制输出格式。例如，在引用[4]的Golang代码中，模式参数被指定为sm2.C1C2C3，那么在Python的gmssl中可能存在类似选项。 假设在Python的gmssl中，可以传递一个参数来指定模式，例如： encrypt_data = sm2_crypt.encrypt(plaintext, mode=SM2_CIPHERTEXT_MODE.C1C2C3) 如果没有这样的参数，可能需要手动处理。例如，加密后的数据是C1C3C2格式，但用户需要C1C2C3，则需要分割字节并重新排列。 或者，可能gmssl默认返回的是ASN.1编码，因此需要解码。根据引用[3]，不同语言的问题源于ASN.1编码的差异，所以如果用户需要原始C1C2C3格式，可能需要避免使用ASN.1，直接拼接各部分。 另外，SM2加密的过程通常包括生成随机公钥C1，计算密钥派生函数得到对称密钥，加密明文得到C2，并计算C3作为摘要。因此，可能需要手动实现这些步骤，而不仅仅依赖库函数。 但手动实现SM2加密较为复杂，涉及椭圆曲线运算、密钥派生函数、哈希等。因此，更实际的方法是使用现有的库，并调整输出格式。 总结可能的解决方案： - 使用gmssl库的sm2模块，调用encrypt方法，并指定输出格式为C1C2C3。 - 如果库不支持指定格式，可能需要解析返回的字节流，分割为C1、C2、C3并重新排列。 - 或者，检查加密后的字节长度是否符合预期，例如65+len(明文)+32，然后手动分割。 例如，如果明文是"ABC123"，长度是6字节，那么加密后的总长度应为65+32+6=103字节。根据引用[3]，总长度可能为65+32+明文长度=102字节（例如明文5字节时总长度102），所以需要确认各部分长度是否正确。 假设使用gmssl的sm2.Encrypt返回的是C1C3C2格式的原始字节，那么用户需要的是C1C2C3，则需要将中间的C3和C2交换位置。例如，将密文拆分为C1（65字节）、C3（32字节）、C2（明文长度字节），然后重新拼接为C1 + C2 + C3。 但具体如何分割需要明确各部分的长度。例如，加密后的数据可能结构为：C1（65字节） || C3（32字节） || C2（n字节）。要转换为C1C2C3格式，就需要将C3和C2的位置交换，变为C1 || C2 || C3。 因此，在Python中，可以这样处理： ciphertext = sm2.encrypt(plaintext) c1 = ciphertext[0:65] c3 = ciphertext[65:97] c2 = ciphertext[97:] desired_ciphertext = c1 + c2 + c3 但需要确认gmssl返回的密文是否确实是这种结构。可能需要实际测试或查阅文档。 此外，根据引用[3]中的描述，原始数据是C1 || C3 || C2，而ASN.1编码的密文则不同。因此，如果gmssl默认返回的是原始数据，那么直接分割即可。如果返回的是ASN.1编码的，则需要解码。 例如，在引用[3]中，使用OpenSSL生成的密文是ASN.1编码的，需要解码才能得到原始C1C3C2。而用户需要的是原始拼接的C1C2C3。因此，可能需要先解码ASN.1，然后重新排列。 但若gmssl的encrypt函数直接返回原始拼接的C1C3C2，而用户需要C1C2C3，则需要手动调整。 综上所述，可能的Python实现步骤如下： 1. 安装gmssl库：pip install gmssl 2. 导入所需模块： from gmssl import sm2, func 3. 生成SM2密钥对： private_key = '00...' # 64字节的16进制字符串 public_key = '04...' # 130字符的16进制字符串，包括04前缀 4. 初始化SM2对象： sm2_crypt = sm2.CryptSM2(public_key=public_key, private_key=private_key) 5. 加密明文，并指定模式（如果支持）： ciphertext = sm2_crypt.encrypt(b'ABC123', mode='C1C2C3') # 假设存在模式参数 6. 如果没有模式参数，可能需要处理返回的字节： # 假设返回的是C1C3C2格式 c1 = ciphertext[:65] # 65字节 c3 = ciphertext[65:97] # 32字节 c2 = ciphertext[97:] # 明文长度字节 desired_ciphertext = c1 + c2 + c3 7. 将desired_ciphertext转换为十六进制字符串或其他所需格式。 但需要测试gmssl的encrypt函数返回的实际结构。例如，加密后的数据长度是否符合预期。假设明文为"ABC123"，长度6字节，加密后的总长度应为65+32+6=103字节。如果实际加密后的长度是103字节，那么可以分割处理。 然而，根据引用[4]中的Golang示例，加密后的字符串是C1C2C3格式，可能gmssl的默认输出已经是该格式，或者需要指定模式。 可能需要查阅gmssl的文档或源代码。例如，查看sm2.py中的encrypt函数定义。假设在sm2.CryptSM2的encrypt函数中，有一个参数可以指定模式，如c1c2c3=True。 假设没有该参数，则可能需要手动调整。 另外，在引用[3]中提到，SM2密文的原始格式是C1 || C3 || C2，而ASN.1编码的密文则是另一种结构。因此，如果gmssl的encrypt返回的是原始格式，那么用户需要的是将C3和 C2的位置交换，变成C1 || C2 || C3。 例如，原始密文是C1(65) + C3(32) + C2(n)，用户需要C1 + C2 + C3，所以需要分割并重新拼接。 因此，Python代码可能如下： plaintext = b"ABC123" ciphertext = sm2_crypt.encrypt(plaintext) c1 = ciphertext[:65] c3 = ciphertext[65:97] c2 = ciphertext[97:] desired_ciphertext = c1 + c2 + c3 然后，desired_ciphertext就是C1C2C3格式的密文。 但需要验证gmssl的encrypt函数是否确实返回C1C3C2的结构。例如，使用示例数据测试。 假设用户运行以下代码： from gmssl import sm2, func private_key = '00' * 32 # 示例私钥 public_key = '04' + '00' * 64 # 示例公钥 sm2_crypt = sm2.CryptSM2(public_key=public_key, private_key=private_key) ciphertext = sm2_crypt.encrypt(b'abc') print(len(ciphertext)) # 输出长度 如果明文是3字节（'abc'），则C1是65字节，C3是32字节，C2是3字节，总长度100字节。如果输出长度是100，则说明结构正确，可以分割处理。 否则，如果长度不同，可能需要调整分割方式。 总结，可能的实现步骤为： - 使用gmssl库生成密钥对 - 使用encrypt方法加密明文，得到原始密文 - 分割密文为C1、C3、C2 - 重新拼接为C1C2C3格式 最后，用户需要确保在解密时也按照相同的结构处理。例如，解密函数可能需要接收C1C2C3格式，并将其转换为库期望的格式（如C1C3C2），再解密。 此外，引用[3]提到不同语言之间的问题，所以生成C1C2C3格式可能需要与其他系统兼容，确保解密端也使用相同的排列顺序。 因此，最终的Python代码可能如下： from gmssl import sm2, func # 生成密钥对（示例） private_key = '00' * 32 public_key = '04' + '00' * 64 # 假设公钥格式正确 sm2_crypt = sm2.CryptSM2(public_key=public_key, private_key=private_key) # 加密 plaintext = b"ABC123" ciphertext = sm2_crypt.encrypt(plaintext) # 分割为C1(65)、C3(32)、C2 c1 = ciphertext[:65] c3 = ciphertext[65:97] c2 = ciphertext[97:] # 重组为C1C2C3 c1c2c3 = c1 + c2 + c3 print("C1C2C3格式密文:", c1c2c3.hex()) 但需要实际测试这段代码，确认分割是否正确，以及加密后的密文结构是否符合预期。 如果gmssl的encrypt函数默认返回的是C1C3C2，那么上述代码将正确重组为C1C2C3。否则，可能需要调整分割的位置。 另外，用户需要注意公钥的正确格式，是否包含0x04前缀，如引用[3]所述，C1部分包括前缀0x04，然后是x和y各32字节，共65字节。 因此，在生成公钥时，需要确保公钥的格式正确，否则加密可能失败。 最后，用户可能还需要处理其他细节，如编码问题、错误处理等，但核心步骤是上述内容。</think>在Python中实现SM2加密算法生成c1c2c3格式密文，可通过以下步骤实现： ### 实现步骤 1. **安装依赖库** ```bash pip install gmssl ``` 2. **密钥生成与加密实现** ```python from gmssl import sm2, func import binascii # 初始化SM2对象（示例密钥） private_key = "00" * 32 # 64位十六进制私钥 public_key = "04" + "00" * 64 # 130位十六进制公钥（含0x04前缀） sm2_crypt = sm2.CryptSM2(public_key=public_key, private_key=private_key) # 加密并处理c1c2c3格式 plaintext = b"ABC123" ciphertext = sm2_crypt.encrypt(plaintext) # 分割原始密文（假设库返回C1C3C2格式） c1 = ciphertext[:65] # 公钥点（65字节） c3 = ciphertext[65:97] # SM3摘要（32字节） c2 = ciphertext[97:] # 密文数据（与明文等长） # 重组为c1c2c3格式 c1c2c3 = c1 + c2 + c3 print("C1C2C3格式密文:", binascii.hexlify(c1c2c3).decode()) ``` ### 关键说明 1. **密钥格式** - 公钥需包含`0x04`前缀，后接64字节椭圆曲线坐标（x+y）[^3] - 私钥为32字节十六进制字符串 2. **密文结构** - **C1**：随机生成的临时公钥点（65字节，含`0x04`前缀） - **C2**：加密后的密文数据（长度与明文相同） - **C3**：SM3哈希摘要（32字节）[^3] 3. **跨语言兼容性** - 需确保加解密双方使用**相同字节顺序**（如C1C2C3或C1C3C2） - 若需与其他语言交互，可能需处理ASN.1编码问题[^3] ### 验证解密 ```python # 解密重组后的c1c2c3密文 recovered_plaintext = sm2_crypt.decrypt(c1c2c3) print("解密结果:", recovered_plaintext.decode()) ```
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值