如何处理AES点播的IV / Nonce / Counter？ [英] How to handle the IV/Nonce/Counter for AES CTR?

问题描述

import javax.crypto.Cipher;

public abstract class Crypto {


    private static final String CIPHER_ALGORITHM = "AES/CTR/NoPadding";
    private String AesKeyString = "ByWelFHCgFqivFZrWs89LQ==";

    private void setKey() throws NoSuchAlgorithmException{
        byte[] keyBytes;
        keyBytes = Base64.getDecoder().decode(AesKeyString);
        aesKey = new SecretKeySpec(keyBytes, "AES");
    }

    protected byte[] execute(int mode, byte[] target, byte[] iv) 
            throws Exception{
        Cipher cipher = Cipher.getInstance(CIPHER_ALGORITHM);
        IvParameterSpec ivSpec = new IvParameterSpec(iv);
        cipher.init(mode, aesKey, ivSpec);
        return cipher.doFinal(target);
    }

}

根据 NIST建议 - 附录B，构建初始计数器块有两种有效的方法（AES是128位分组密码）：

According to NIST Recommendation - Appendix B, there are two valid approaches to construct the initial counter blocks (AES is a 128-bit block cipher):

1. 128位nonce与 m 计数器值（通常为32位）。


2. 64位计数器前置64位计数器。

1. 128-bit nonce XORed with an m-bit counter value (usually 32 bits).
2. 64-bit nonce prepended to a 64-bit counter.

我的问题是：

• 在em中使用
  的初始计数器块的确切程序是什么> AES / CTR / NoPadding javax.crypto.Cipher的实例（假定SunJCE为提供者）？
  那就是，给出了上面的代码，使用了初始计数器块的以前的方法中的哪一个，如果有的话呢？

• What is the exact procedure regarding the initial counter block used in an "AES/CTR/NoPadding" instance of javax.crypto.Cipher (assuming SunJCE as the provider)? That is, given the above code, which of the previous approaches for the initial counter block is used, if any?

推荐答案

Java只是选择你建立柜台的方式。您只需要使用16字节IV初始化CTR模式，这只不过是初始计数器值。

Java simply leaves the choice of the way you construct the counter to you. You simply have to initialize the CTR mode using a 16 byte IV, which is nothing more than the initial counter value.

一旦你开始加密，它将使用一个计数器全128位。那么再一次，你根本不希望它重新开始，因为这会直接危及明文的安全性。缺点是不直接支持32位XOR方法（如果从$ code> FFFFFFFF 的计数器开始，下一个值将改变计数器的第33位最低有效位）。

Once you start encrypting it will use a counter over the full 128 bits. Then again, you would hardly want it to start over as that would directly compromise the security of the plaintext. The disadvantage is that the 32 bit XOR method is not directly supported (if you start with a a counter of FFFFFFFF the next value will alter the 33rd least significant bit of the counter).

再次，我宁愿选择一个8字节的随机数，并将最低有效位设置为全零。或者选择GCM模式。

Then again, I would rather choose a 8-byte nonce and leave the least significant bits set to all zeros. Or choose GCM mode of course.

证明：

Cipher aesCTR = Cipher.getInstance("AES/CTR/NoPadding");
SecretKey aesKey = new SecretKeySpec(new byte[16], "AES");
IvParameterSpec lastIV = new IvParameterSpec(Hex.decode("FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF"));
aesCTR.init(Cipher.ENCRYPT_MODE, aesKey, lastIV);
byte[] twoBlocks = aesCTR.doFinal(new byte[2 * aesCTR.getBlockSize()]);
byte[] secondBlock = Arrays.copyOfRange(twoBlocks, 16, 32);
System.out.printf("%s%n", Hex.toHexString(secondBlock));

IvParameterSpec firstIV = new IvParameterSpec(new byte[16]); // all zero IV
aesCTR.init(Cipher.ENCRYPT_MODE, aesKey, firstIV);
byte[] oneBlock = aesCTR.doFinal(new byte[aesCTR.getBlockSize()]);
System.out.printf("%s%n", Hex.toHexString(oneBlock));

---

输出：

---

Output:

66e94bd4ef8a2c3b884cfa59ca342b2e
66e94bd4ef8a2c3b884cfa59ca342b2e

这篇关于如何处理AES点播的IV / Nonce / Counter？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！