本周三给部门里全球的同事做了个 设计安全原则 的讲座，昨天有个做iOS的同事找到我，说遇到RSA解密跟后端和Android端不一致的问题。诶？！说明这个讲座还是有人听进去了，而且枯燥的主题下（讲“原则”）的全英文session，他还能听出来我在安全实战方面的经验丰富，老夫不禁感到老怀大慰！
这个问题定位的过程还是很有意思的，值得一记！先总结一下结果，我们再来看一则对话。
总结
- 程序员问问题会比较天马行空，想到啥就问啥。他/她们往往设想某个地方没问题，然后问的时候，把你往一些他关注的地方带。作为大佬，一定要了解全局，从最基础的地方了解起，不要放过任何一个细节。有时候他们会很生气，觉得你不信任他们，问那么愚蠢的问题。这时候一定要坚持做没情感的纠错机器人，要怀疑一切，不能相信他们，如果他们的假设是成立的，那又怎么会找不到问题呢？对吧？！
- iOS 的基础库良莠不齐，有些地方用c做字符串，这会造成截断现象！
对话...
问者：
Hi 山哥
想咨询下关于RSA加解密的问题 最近项目遇到偶发的解密出来的明文数据 长度异常 比预期要短 偶现的问题 是在iOS端
把iOS生成和publicKey跟 privateKey给API那边 他们用publicKey来加密privateKey 解密 数据是正常的
关于这个有没有什么解决思路 期待你的回复 谢谢
山哥：问题是 解密出来的结果不正确？
问者：对 长度不对
能解出来 但是长度明显比较短
山哥：我想了解一下整个流程。是不是：
iOS 加密，api 解密，偶发现象是“出来的结果不对”？还是说加密解密都是iOS做的，然后偶发出错现象？
问者：API加密 iOS解密
（编者按：... 附上一堆长长的 keys in hex，可以看到hexPublicKey, hexPrivateKey, encrypted3DESKey）这些字样）
decrypted3DESkey=17F6 这个长度预期是60位
但是实际解出来只有4位
偶发的bug
山哥：所以你加密的对象是3DES的key？
（思路：看起来像是HTTPS的原理，先用 非对称密钥 来生成一个临时的 对称密钥，再用来加解密通讯...）
问者：ios生成RSA的keyPair把publicKey给API, API加密3DESKey 然后iOS再解密3DESKey
api加密ios解密
山哥：拿到这个3DESKey之后，如果key size感觉，是不是就出现双方无法通讯的问题？这个key是用来双方通讯的吧
问者：对的
就是解出来 发现keySize异常 后续通讯失败
山哥：初步怀疑是有时候后端生成的key有特殊字符，比如'\0', 在iOS被截断了。是不是Android没有这样的问题？
(思路：大胆假设，小心求证！iOS底层是oc, c 的字符串是用'\0' 来标记结束的。虽然不知道解密为什么会用到字符串，但这种失败也很少见?。?/code>)
问者：AOS没有这个问题
山哥：你先把这个key, 用Java解密之后，打印个byte[]的 int 数值出来，看看有没有 0。先确认问题，再想办法解决。
问者：好
问者：48 28 4 ... -42 0 23 -10
里面是有个0, 截断的果然就是0 后面的没有了
...
实锤了！
