使用AES-GCM的协议的nonce / IV的来源和重要性 [英] Source and importance of nonce / IV for protocol using AES-GCM

查看:6410
本文介绍了使用AES-GCM的协议的nonce / IV的来源和重要性的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在制作一个使用AES加密的数据包(即不是流)的协议。我决定使用GCM(基于CTR),因为它提供集成身份验证,并且是NSA的Suite B的一部分。使用ECDH协商AES密钥,其中公钥由受信任的联系人签名,作为Web-使用类似ECDSA的东西。 我相信我需要一个128位的nonce /初始化向量为GCM,因为即使我使用256位密钥为AES,它总是一个128位块密码(右?)在读取BC代码后使用96位IV。

I am making a protocol that uses packets (i.e., not a stream) encrypted with AES. I've decided on using GCM (based off CTR) because it provides integrated authentication and is part of the NSA's Suite B. The AES keys are negotiated using ECDH, where the public keys are signed by trusted contacts as a part of a web-of-trust using something like ECDSA. I believe that I need a 128-bit nonce / initialization vector for GCM because even though I'm using a 256 bit key for AES, it's always a 128 bit block cipher (right?) I'll be using a 96 bit IV after reading the BC code.

我绝对不是实现自己的算法(只是协议 - 我的加密提供程序是BouncyCastle),但是我仍然需要知道如何使用这个nonce不射击自己在脚。在具有相同DH密钥的两个人之间使用的AES密钥将保持不变,因此我知道相同的随机数不应该用于多个数据包。

I'm definitely not implementing my own algorithms (just the protocol -- my crypto provider is BouncyCastle), but I still need to know how to use this nonce without shooting myself in the foot. The AES key used in between two people with the same DH keys will remain constant, so I know that the same nonce should not be used for more than one packet.

我只是在数据包前面加一个96位伪随机数,并让收件人使用它作为一个随机数?这是对等软件,并且可以在任何时间发送分组(例如,即时消息,文件传输请求等),并且速度是一个大问题,因此不必使用安全随机数源。现在不一定是秘密,对吧?或者必然是随机的加密安全PNRG?维基百科说它应该是随机的,否则它容易受到选择明文攻击 - 但是有两个声明旁边的需要引用,我不知道这是否对于块密码是真的。我实际上可以使用一个计数器,计数发送的数据包数量(独立于128位块的计数器)与给定的AES密钥,从1开始?显然,这将使得临时值可预测。考虑到GCM认证和加密,这会危及其认证功能吗?

Could I simply prepend a 96-bit pseudo random number to the packet and have the recipient use this as a nonce? This is peer-to-peer software and packets can be sent by either at any time (e.g., an instant message, file transfer request, etc.) and speed is a big issue so it would be good not to have to use a secure random number source. The nonce doesn't have to be secret at all, right? Or necessarily as random as a "cryptographically secure" PNRG? Wikipedia says that it should be random, or else it is susceptible to a chosen plaintext attack -- but there's a "citation needed" next to both claims and I'm not sure if that's true for block ciphers. Could I actually use a counter that counts the number of packets sent (separate from the counter of the number of 128 bit blocks) with a given AES key, starting at 1? Obviously this would make the nonce predictable. Considering that GCM authenticates as well as encrypts, would this compromise its authentication functionality?

推荐答案

GCM 是一个块密码计数器模式。计数器模式有效地将块密码转换为流密码,因此用于流密码的许多规则仍然适用。重要的是注意,相同的Key + IV将总是产生相同的PRNG流,并且重新使用该PRNG流可以导致攻击者用简单的XOR获得明文。在协议中,相同的Key + IV可以用于会话的生命期,只要模式的计数器不包装(int overflow)。例如,协议可以具有两个方,并且它们具有预共享的秘密密钥,然后它们可以协商用作每个会话的IV的新的加密的随机数(记住随机数意味着使用仅一次 )。

GCM is a block cipher counter mode with authentication. A Counter mode effectively turns a block cipher into a stream cipher, and therefore many of the rules for stream ciphers still apply. Its important to note that the same Key+IV will always produce the same PRNG stream, and reusing this PRNG stream can lead to an attacker obtaining plaintext with a simple XOR. In a protocol the same Key+IV can be used for the life of the session, so long as the mode's counter doesn't wrap (int overflow). For example, a protocol could have two parties and they have a pre-shared secret key, then they could negotiate a new cryptographic Nonce that is used as the IV for each session (Remember nonce means use ONLY ONCE).

如果你想使用AES作为块密码,你应该查看 CMAC模式或者可能是OMAC1变体。使用CMAC模式,适用于仍然CBC的所有规则。在这种情况下,您必须确保每个数据包使用独特的IV,也随机。然而,重要的是注意,重用IV不像重复使用PRNG流一样可怕的后果。

If you want to use AES as a block cipher you should look into CMAC Mode or perhaps the OMAC1 variant. With CMAC mode all of the rules for still CBC apply. In this case you would have to make sure that each packet used a unique IV that is also random. However its important to note that reusing an IV doesn't have nearly as dire consequences as reusing PRNG stream.

这篇关于使用AES-GCM的协议的nonce / IV的来源和重要性的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆