在doFinal之后，Java AES/GCM/NoPadding加密不会增加IV的计数器 [英] Java AES/GCM/NoPadding encryption does not increment the counter of the IV after doFinal

问题描述

当我使用默认的AES/GCM算法初始化Cipher对象时，它具有12字节的随机重发IV，但是在调用doFinal时前4个字节不会递增，并抛出 java.lang.IllegalStateException:无法重复使用同一密钥和IV进行多次加密.

When I initialize a Cipher object with the default AES/GCM algorithm, it has a reandom 12 bytes IV but the first 4 byte does not get incremented ater doFinal is called and throws the java.lang.IllegalStateException: Cannot re-use same key and IV for multiple encryptions exception.

SecretKey secretKey = ...

final Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
cipher.init(Cipher.ENCRYPT_MODE, secretKey);

byte[] iv1 = encCipher.getIV();
byte[] ctext = encCipher.doFinal("a".getBytes());
      
cipher.update("b".getBytes());
byte[] iv2 = encCipher.getIV();
ctext = encCipher.doFinal();

推荐答案

java.lang.IllegalStateException:无法为多个加密异常重复使用相同的密钥和IV.

java.lang.IllegalStateException: Cannot re-use same key and IV for multiple encryptions exception.

这是为了保护您，希望该库至少在同一个Cipher对象下使用时保持这种行为.

This is for your protection and hopefully, the library keeps this behavior at least when used under the same Cipher object.

AES-GCM内部在CTR模式下使用AES进行加密，而对于CTR模式，(密钥，IV)对的重用是婴儿床拖曳导致机密性的灾难性失败.

The AES-GCM internally uses AES in CTR mode for encryption and for CTR mode the reuse of the (key,IV) pair is a catastrophic failure of the confidentiality by the crib-dragging.

AES-GCM使用12字节IV/nonce，其余部分用于计数器.前两个计数器值是保留值，因此您最多可以加密2 ^ 32-2块，这将形成2 ^ 39-256位，并且在单个(IV，密钥)对下大约有68 GB.

The AES-GCM uses 12-byte IV/nonce and the remaining is used for the counter. The first two counter values are reserved so you can encrypt at most 2^32-2 blocks and that makes 2^39-256 bits and makes around 68-GB under a single (IV, key) pair.

NIST 800-38d是标准的12字节随机数.如果您提供不等于12字节的随机数，则将使用 GHASH 对其进行处理.code>，之后将是12个字节.

The 12-byte nonce is standard by the NIST 800-38d. If you supply a nonce not equal to 12-byte, then it will be processed with GHASH and the size will be 12-byte after that.

if len(IV) = 96 then 
    J_0 = IV || 0^{31}1
else 
    J_0=GHASH_H(IV||0^{s+64}||len(IV_64))

不建议您按照NIST的建议使用基于计数器的IV生成，因为它将成功随机的.此外，由于进行了GHASH调用，它会使您的加密速度变慢.

It is not advised if you use counter-based IV generation as suggested by NIST because it will make it random. Also, it will make your encryption a bit slower due to the GHASH call.

当我使用默认的AES/GCM算法初始化一个Cipher对象时，它具有一个随机的12字节IV，但是前4个字节没有递增

When I initialize a Cipher object with the default AES/GCM algorithm, it has a reandom 12 bytes IV but the first 4 byte does not get incremented

这是预期的结果.对方再次设置为零.由于文件大于计数器支持，您是否要继续保留它的剩余位置?分割文件并建立链接.

This is what expected. The counterpart is set to zero again. Do you want to continue where it is left since your file is larger than the counter supports? Divide the file and make chain.

• 此外，请参见正确使用AES-GCM的规则是什么?
• 只要标签不正确，就不要使用纯文本.
• 存在AES-GCM-SIV模式，可以消除对(IV，key)对的滥用.只会泄漏使用相同的IV和密钥再次发送相同的消息.
• TLS实际上每条记录使用一个新的(密钥，IV)对，该对最多具有2 ^ 14字节，这可以防止内存填充攻击.考虑到您将内存花费在解密68 GB上，那么您已经看到该标签不正确.服务器的不错的DOS攻击点.
• 在可用的情况下，使用ChaCha20-Poly1305比AES-GCM容易得多.但是，它仍然具有(IV，密钥)重用问题.
• 有一个XChaCha20，它使用192位随机数和64位计数器.这样可以安全地处理非常大的数据量和随机数.

这篇关于在doFinal之后，Java AES/GCM/NoPadding加密不会增加IV的计数器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！