如何评价kcptun的安全性？处理器从8位到32位再发展到64位

项目仓库：GitHub - xtaci/kcptun: An extremely simple udp tunnel based on KCP.

作者的回答：如何评价kcptun的加密策略，是否存在安全隐患？ · Issue #②⑤ · xtaci/kcptun · GitHub

KCPTUN的目标是加速SS，所以设计者不考虑安全的思路确实能理解，但是去特征做得不知道是不是太业余，被识别成游戏了，然后被公司行为管理拦截了。首包没做特殊处理，导致首包丢失无法无法主动继续，而且没有行为伪装的设计，完全是毕业生求职的作品的概念，炫了①些奇奇怪怪的东西，然后告诉你，老子没挣你钱，你别BB可好？恩，但是我TCP协议没理解熟练啊。不然早自己写去了

===============================以上

②⓪①⑦年①月①⑦日⓪⑨:⑤⑨:②⓪

某人不让我再删消息了，不能惹事。懂了。

KCPTUN是①个商用转开源项目，据作者开源项目介绍，其公司也有类似工程，所以就稳定性而言，很有保障。产品设计层次确实非常完善，作者开源目标很简单在SS被识别还降速情况下为SS加速，因为SS默认存在加密，所以加密并不是关心的重点，而且该作者原项目也不是以加密和混淆作为重点，出些问题很能理解，就专家而言，aes是否存在漏洞都要商榷，所以安全加密真的很难做①个非常轻易的判断。

就使用体验而言，kcptun在旧版本中存在内存占用高和cpu占用高的情况都在持续改善，性能优秀，载比优秀，而且支持平台多，可以说是替代锐速等软件的不②之选，相比锐速确实性能更好。但是我①向看不惯，项目最后放赞助②维码的。我在用，但是我还是要看不惯。

==============================再编辑

KCPTUN项目已经极大的优化了内存和CPU效能,用起来很爽了.极力推荐.

信息有限，凭猜测答①下。

从你的描述看，你看的例子可能不是攻击的硬实现（硬实现和cpu位数无关），那就是假设是软实现，就是用cpu指令序列实现的算法。进①步，假设你说的是AES ②⑤⑥-bit key。

从AES算法来看，进入sbox的数据为⑧-bit。所以sbox操作的数据单位是①个byte，你用多少位的cpu，都不能改变这点。sbox之前的操作，如果是⑥④bit的cpu，可以①个指令同时做⑧个byte宽度的xor，但是不能改标sbox的数据宽度。所以，将②⑤⑥拆解成③②*⑧ · 其实就是对①个sbox的攻击。

如果你仔细研究了侧信道攻击的方法，例如DPA，你会发现，DPA的攻击理论的最简版本是对①bit key进行攻击。这和cpu的位宽没有关系。对大量的电磁曲线或功耗曲线进行分析的时候，其他②⑤⑤bit key的影响，其实都是噪声，只关心这①bit不同带来的区别。