Update zuc.c

[haozekang]

参考中国科学院软件研究所在18年发表的【祖冲之算法：ZUC-256算法草案】，修复ZUC256MAC。

PDF：https://www.is.cas.cn/ztzl2016/zouchongzhi/201801/W020180416526664947206.pdf

这个是在PDF中找到，测试应得到的结果截图：

这个是编译代码得到的结果截图：

我不是密码学专业的，只是在项目中使用到ZUC256MAC算法时，发现GmSSL和bc-csharp的计算结果不一致。所以浅浅的研究了一下，如有错误，还望大神指点一二

[haozekang]

这个URL也可以，上面那个证书失效了，https://is.cas.cn/ztzl2016/zouchongzhi/201801/W020180416526664947206.pdf

[guanzhi]

你上面的测试代码，以及bc-csharp的实现我觉得是有误的。在ZUC256的草案中，IV值总计是184比特，其中IV0-IV16是8比特的值，IV17-IV24是6比特的值。那么应该以多少字节来存储这184比特的IV值呢？184/8 =23，因此应该用23字节来存储，而不是25个字节。

由于ZUC256草案是在比特层面描述这个算法规范，而没有指定字节存储层面或者编程接口层面的格式，用25字节来传输或者存储184比特的IV也是可以的，但是这样会带来一些潜在的问题：

1. IV17-IV24中每个字节中有2个比特没有被用到，不管设置为任何值都不影响算法执行的正确性。但是这些比特可能带来隐藏信道或者其他的安全问题。比如一个不开源的恶意ZUC256实现，可以通过IV中特定的IV无效比特，触发其执行某些恶意行为。
2. 原本只需要23个字节就可以表示完整的IV，用25个字节增加了不必要的存储开销。
3. 通常如果标准中没有明确指定填充方式（或校验值），那么应该以紧凑方式存储所有的数据，以8比特存储6比特值，容易导致实现的兼容性问题。

如果需要保证GmSSL和25字节IV实现之间的兼容性，那么可能需要自己编程实现两种IV表示之间的转换。

[haozekang]

好的，谢谢