SM4 GCM加解密中J0之后的CTR问题

[lan-n]

gmssl源码中SM4 GCM中CTR相当于用的是128bit，是不是应该用32bit的ctr？

[lan-n]

gcm在J0之后会使用inc32使j0递增，再进行加解密，这里的inc32应该是32bit的counter进行自增，但是源码是128bit的，即使用的是16byte，这点到底是32bit呢还是128bit？

[deatil]

ctr是sm4的blocksize大小。sm4是16，如果是其他对称加密就是可能不是16。
gcm 是 gcm 的 blocksize 大小

[emmansun]

GCM模式没有相应国密规范，都参考NIST Special Publication 800-38D。本项目实现中CTR/GCM模式共用同一个ctr_inc实现，这是有问题的，特别是当IV/nonce不是12字节（96位）、Seal的Blocks数量多，导致32位数进位的时候。

[lan-n]

GCM模式没有相应国密规范，都参考NIST Special Publication 800-38D。本项目实现中CTR/GCM模式共用同一个ctr_inc实现，这是有问题的，特别是当IV/nonce不是12字节（96位）、Seal的Blocks数量多，导致32位数进位的时候。

我也觉得，当遇到counter翻转的时候，算出来的结果就不对了。因为正常是只翻转4byte，有12byte值保持不变，而gmssl是翻转16byte。这样计算出来的结果就和openssl对不上。

[emmansun]

和 #1305 重复。有个PR：#1610 ，但是看着好像把CTR模式改错了，反而sm4_modes中的gcm函数没改。

[lan-n]

和 #1305 重复。有个PR：#1610 ，但是看着好像把CTR模式改错了，反而sm4_modes中的gcm函数没改。

#1305我感觉他这里
if (a[i] != 255)
{
a[i]++;
break;
}
这里处理得不太对，还是可以保持gmssl源码的原有的处理。因为如果a[15] = 0xFF，那应该要把a[15]++, 即a[15]变成0，a[15]~a[12]都应该变成0，然后才退出。

[emmansun]

和 #1305 重复。有个PR：#1610 ，但是看着好像把CTR模式改错了，反而sm4_modes中的gcm函数没改。

#1305我感觉他这里 if (a[i] != 255) { a[i]++; break; } 这里处理得不太对，还是可以保持gmssl源码的原有的处理。因为如果a[15] = 0xFF，那应该要把a[15]++, 即a[15]变成0，a[15]~a[12]都应该变成0，然后才退出。

确实，我看错了，#1305 是理解错误。

[guanzhi]

GCM中counter overflow问题在最近的更新中做了修正，还有待进一步测试