关于SM2算法 ASN.1编码 踩过的坑 - 加密

 在某些项目开发过程中，或多或少很多底层安全OS系统或者算法库，都引入了openssl或者gmssl的一些内容来实现算法，这样就导致算法运算结果并不是完全按照国密标准的裸数据，而是经过编码之后的数据，编码之间的对齐对上层业务系统互通带来的一些挑战。

以一个手机TEE里面TA实际出现的场景举例，APP应用访问TA进行算法运算，在TA里面进行SM2算法加密之后，正常情况下TA结果为 C1x+C1y+C3（Hash）+ C2(CipherText)，经过ASN.1编码后正常数据（以加密22个字节数据为例）为：

307E
0220
31F54CC0FDE5CD157B1FB0649C94E527C615175F20728D377BEC41115382709A  /*C1x*/
0220
74C5BFA964DB81FC7C298C3D580725455747D1459DEED2948C4741299D95DEA3 /*C1y*/
0420
022A51ABEC9ACFEE8E2F5438A4526C8084600CDE3CB26188237194E594F3DEC2 /*Hash*/
0416
32BDB7F56DA4C7C444A2CAF5489FC5E628E40DB3CD06 /*CipherText*/

但实际系统里面，在C1x\C1y这块会偶然出现一些意想不到的结果，如:

307D
0220
15A7280C39E3CB96960931170ED40CE286B89AC6E623D1E2A29C492AB2BC7F6E  /*C1x*/
021F
7C9B7B1DA124AC10ADB08B2AD9D07B4737326ACD2C9E07173DD786B79595f8   /*C1y*/
0420
882CC28818D3DF5287071A1B7DBA37150583D2C3F90E5B44B319A68ABF675B5B  /*Hash*/
0416
7C8D9C9895DCA83E35D85C5318384323725D67CF744B/*CipherText*/

两个数据的差异在于：

C1y的长度不一样，正常为32个字节，不正常的为31个字节，如果直接取数据会导致业务异常。

经过分析发现，C1y的数据也是对的，原因是C1y丢失的那个字节是为0，不计算在长度里面，在上层业务系统中，需要进行补0 操作。