作者回复: 现有技术没有出现明显的问题,所以大家还是习惯性使用传统的算法,这些新算法的替代性和普及性不会那么高。
另外,不要低估国密,最近和一些数据安全的人聊,他们表示如果只做国内业务的话,最好都用国密。因为说不定哪天等保或者国内的数据安全法,就强制要求国密了。
作者回复: 你好,感谢你的留言。如果一定要追究依据的话,可以查阅字典,只有钥匙读yao。这其实是北京人的方言发音,钥其实是只有yue这个读法的。
不过嘛,字典也会适应潮流,将错就错,比如‘空穴来风’的意思。所以,科普yue仅仅是我的偏执,不需要认同。
作者回复: 你好,感谢你的留言。这个问题之前还真没注意到,特地查了一下。看到的原因也就是“due to the availability of faster algorithms”。也就是说,已经有更快更好的AES了,就没有再使用IDEA的意义了。
作者回复: 理论是这样没错,但实际使用时,你肯定不会有那么多数据需要去做散列。所以,追求的是在有限数据量下,碰撞概率几乎为0。
作者回复: 这个总结可以,我都没想到。
作者回复: 哈哈,官方实锤~
作者回复: 你好,感谢你的留言。在https中使用了DH密钥交换算法实现的。可以想象成一边出一半的密钥,然后就能够拼成一个完整密钥。因篇幅限制,课程中没有具体讲。
作者回复: 盐值是和账号作唯一关联,且不变的。
作者回复: 加密强度高。SM2和ECC的原理是一致的,都是椭圆曲线算法。ECC的缺陷在于,生成一组密钥的时间耗时比较长,因此性能上会有一定影响。
作者回复: 我理解的Bcrypt其实就是散列+盐的封装实现,作为一种最佳实践的封装,安全性上应该不会出现太大问题。
作者回复: 只是加密后密文的比对?那似乎没有加密的必要,散列算法就可以了。
作者回复: 密钥保密传递是需要自己通过可信通道传递的。除此之外,很多时候也会用dh算法,作可信的对称密钥协商,https就是这么干的。
作者回复: 你好,感谢你的留言。黑客确实可以利用盐建立新的彩虹表,但是这意味着黑客需要为每一个用户建立一张彩虹表,而建表的过程,其实就和暴力破解的效果一样了。
作者回复: 协商密钥是非对称的,密钥协商完之后就是对称加密了。
盐值一般和用户名等唯一标识放一块。盐值不用考虑保密性,只要完全随机且唯一对应即可。
作者回复: 后续课程会逐步覆盖的~
作者回复: 非对称加密,公玥不需要保密,存储到前端即可。
作者回复: 这就是国家层面的考量了。一方面,是对加密算法的安全性考量,比如DES中可能的后门。另一方面,也是对专利版权的保护,毕竟自己的专利,自己才有可控性。这就和芯片一样,现在用外国的没啥问题,哪天它不让你用了呢?
作者回复: 第一句说反了。对称效率高,非对称效率低。