Hut*_*ut8 12 security cryptography aes block-cipher
我正在制作一个使用AES加密的数据包(即非流)的协议.我决定使用GCM(基于CTR),因为它提供了集成身份验证,并且是NSA套件B的一部分.使用ECDH协商AES密钥,其中公钥由可信联系人签名,作为网络的一部分 - 使用像ECDSA这样的信任.我相信我需要一个用于GCM的128位随机数/初始化向量,因为即使我使用256位密钥进行AES,它总是一个128位分组密码(对吗?) 我将使用96位IV后阅读BC代码.
我绝对没有实现我自己的算法(只是协议 - 我的加密提供程序是BouncyCastle),但我仍然需要知道如何使用这个nonce而不用自己的脚.在具有相同DH密钥的两个人之间使用的AES密钥将保持不变,因此我知道不应将同一个随机数用于多个数据包.
我可以简单地在数据包前加一个96位伪随机数,并让收件人将其用作nonce吗?这是点对点软件,数据包可以随时发送(例如,即时消息,文件传输请求等),速度是一个大问题,所以最好不要使用安全随机数源.nonce根本不必是秘密的,对吧?或者必然像"加密安全"PNRG一样随机?维基百科说它应该是随机的,否则它很容易受到选择的明文攻击 - 但是两个声明旁边都有一个"需要引用",我不确定这是否适用于分组密码.我是否可以使用一个计数器来计算从给定的AES密钥开始的1个发送的数据包数(与128位数的计数器分开)?显然这会使nonce可预测.考虑到GCM进行身份验证以及加密,这是否会损害其身份验证功能?
GCM是具有身份验证的分组密码计数器模式.计数器模式有效地将分组密码转换为流密码,因此流密码的许多规则仍然适用.重要的是要注意,相同的Key + IV将始终产生相同的PRNG流,并且重用此PRNG流可能导致攻击者通过简单的XOR获得明文.在协议中,只要模式的计数器不包装(int溢出),就可以在会话的生命周期中使用相同的Key + IV.例如,协议可以有两方并且它们具有预共享密钥,然后它们可以协商用作每个会话的IV的新加密Nonce(记住nonce意味着仅使用ONCE).
如果要将AES用作分组密码,则应查看CMAC模式或OMAC1变体.使用CMAC模式,仍适用于CBC的所有规则.在这种情况下,您必须确保每个数据包使用一个也是随机的唯一IV .然而,重要的是要注意重用IV不会像重用PRNG流那样产生可怕的后果.
| 归档时间: |
|
| 查看次数: |
5991 次 |
| 最近记录: |