我已经尝试通过自己在此处查看并在其他地方搜索了很长时间来找到答案,但我仍然有一些疑问。
假设这段 Java 代码:
try
{
int cipherMode = Cipher.ENCRYPT_MODE;
SecretKeySpec secretKey = ...; // generated previously using KeyGenerator
byte[] nonceAndCounter = new byte[16];
byte[] nonceBytes = ...; // generated previously using SecureRandom's nextBytes(8);
// use first 8 bytes as nonce
Arrays.fill(nonceAndCounter, (byte) 0);
System.arraycopy(nonceBytes, 0, nonceAndCounter, 0, 8);
IvParameterSpec ivSpec = new IvParameterSpec(nonceAndCounter);
Cipher cipher = Cipher.getInstance("AES/CTR/NoPadding");
cipher.init(cipherMode, secretKey, ivSpec);
File inFile = new File(...);
File outFile = new File(...);
long bytesRead = 0;
try (FileInputStream is = new FileInputStream(inFile);
FileOutputStream os = new FileOutputStream(outFile))
{
byte[] inBuf = new byte[512 * 1024];
byte[] outBuf = new byte[512 * 1024];
int readLen = 0;
ByteBuffer byteBuffer = ByteBuffer.allocate(8);
byteBuffer.putLong(bytesRead);
while ((readLen = is.read(inBuf)) != -1)
{
bytesRead += readLen;
cipher.update(inBuf, 0, readLen, outBuf, 0);
os.write(outBuf);
}
cipher.doFinal(outBuf, 0);
os.write(outBuf);
is.close();
os.close();
}
catch (Exception e) {
System.out.printf("Exception for file: %s\n", e);
}
}
catch (Exception e) {
System.out.printf("Exception: %s\n", e);
}
我的问题是:
关于 CTR 模式的计数器更新,上面的代码是否被认为是正确的?具体来说,我不会自己更新计数器。我应该改用下面的 while 循环吗?我尝试这样做是因为我查看了 cipher.getIV() 在循环中返回的内容,但它没有改变,并且 getIV() 的描述没有详细说明:
while ((readLen = is.read(inBuf)) != -1) { // use offset for last 8 bytes as counter byteBuffer.putLong(bytesRead); System.arraycopy(byteBuffer.array(), 0, nonceAndCounter, 8, 8); bytesRead += readLen; IvParameterSpec ivSpec = new IvParameterSpec(nonceAndCounter); cipher.init(cipherMode, secretKey, ivSpec); cipher.update(inBuf, 0, readLen, outBuf, 0); os.write(outBuf); }
我有更多与修改后的 while 循环方法相关的问题。这样调用cipher.init()可以吗?我这样做是因为我还没有找到只更新 IV 的方法(真的是计数器)。
这么大的 block 大小可以吗,还是应该让它变小?那么它应该有多大呢?
最佳答案
- Is the above code considered OK regarding counter updates for CTR mode?
是的。
但是您可能想要稍微调整一下随机数和计数器的大小。如果您的 nonce 只有 64 位长,由于生日悖论,您可能会在 232 加密后遇到 nonce 冲突(如果接近该点,概率会增加)。如果您对所有这些加密使用相同的 key (我的意思是消息/文件而不是 block )并且发生冲突,这被认为是 CTR 模式的灾难性中断,因为它是两次或多次加密。
您应该考虑使用 96 位随机数和 32 位计数器。缺点是您最多只能安全地加密 232 block ,大约每条消息/文件 68 GB。
- I have more questions related to the modified while loop approach. Is it OK to call cipher.init() in such a way?
没有。
你真的不应该自己更新计数器。请注意,字节和 block 密码 block 之间存在不匹配:您建议的计数器更新使用已经处理过的字节作为新计数器值,它比按 block 计数的自然 CTR 模式计数器前进得更快。您正在耗尽计数器,因此碰撞的可能性越来越大。例如,如果在用数字表示时 nonce 相差 1,则如果 nonce 部分较短而计数器部分较长,则可能会发生重叠。如果随机数是 96 位长,那么您只能安全地加密大小为 68/16 GB = 4.5 GB 的消息/文件。
此外,由于字节/ block 不匹配,这不再是 CTR 模式,您将很难将此代码移植到其他语言。
- Is such a large block size OK or should it be made smaller? In that case how big should it be?
不确定您的意思,AES 具有 128 位或 16 字节的固定 block 大小。
如果您指的是输入/输出缓冲区,那么您应该在您选择的平台上对其进行基准测试以确定。它看起来当然没问题。
关于Java AES CTR IV 和计数器,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45211389/