作者回复: 由于初始化向量不需要保密,可以使用明文传输的初始化向量。每一次加密,都附上初始化向量。传输的数据是:初始化向量 + 密文。以前的TLS就是这么做的。 不过,现在CBC也要快退役了,建议换到Chacha20/Poly1305或者AES-GCM。这两个模式我们稍后会讲到的。
作者回复: #1 就是解决同步问题的办法之一。但是,无论是数据库还是redis,都降低了效率。 #2,这是一个好问题。我写的时候,也想过,这一句是不是会引来讨论。讨论真的就来了。我们后面会讲对加密算法的攻击。重复的初始化向量,一般来说是没有问题的;但是如果没有注意到这些攻击,重复的和已知的初始化向量,会让攻击变得更容易得手。
作者回复: 1)是的,这两种方法是为了让密码不重复。一般来说,攻击者知道IV并不应该有密码学上的风险。文中的这句话,我表达的有失误。 2)如果能直接破解出明文,那就意味着加密算法本身是可以逆运算的。一般情况下,我们都假设加密算法本身的强度是足够的。
作者回复: 嗯,有的时候为了兼容性,要牺牲很多。如果只是本地存储,可能问题还不大;如果要走网络传递,可能会有安全问题。这个还是进一步要分析数据流的场景,才能确定是不是真的有问题。
作者回复: 大概率这个项目的安全性是没有保证的。看看“初始化向量怎么选?”这一小节对你们有没有帮助,或者看看安全协议的设计,比如TLS。
作者回复: 有没有明白初始化向量不能重复的问题?
作者回复: 大部分场景下的初始化向量不需要保密。
作者回复: 重复的iv,相同的明文就有相同的密文,文章里有讲的,这是一般的加密不允许的。下一节我们讲ECB模式。
作者回复: 你问题提的都很好!密钥的限制问题,我们后面专门会讲的。
作者回复: 位数是由数据块的大小确定的。使用随机数或者序列数,是两个解决重复问题的措施,文中有讲的。其他的限制就要看具体的链接模式了,有的还有,有的就没有了,或者我还不知道有没有。