问题标签 [ctr-mode]

我想加密由 web 应用程序编写的 cookie，并且我想将 cookie 的大小保持在最小，因此我选择了 AES/CTR/NoPadding。

你会推荐使用什么作为 IV 足够随机并且仍然保持应用程序无状态。我知道我可以生成一个随机 IV 并将其附加到消息中，但这会增加 cookie 的大小。

此外，对于 128 位 AES，推荐的 IV 大小是多少？

大家是怎么做的呢？是否存在任何“久经考验”的方法？我不想重新发明轮子。

我在 CTR 模式下使用 AES128 加密进行加密，针对不同的客户端（Android/Java 和 iOS/ObjC）实现。加密数据包时使用的 16 字节 IV 格式如下：

每发送一个数据包，数据包计数器（包含在发送的数据包中）就会增加一。最后一个字节用作块计数器，因此少于 256 个块的数据包总是获得唯一的计数器值。我假设 CTR 模式指定计数器应该为每个块增加 1，以大端方式使用最后 8 个字节作为计数器，或者这至少是事实上的标准。Sun 加密实现中似乎也是这种情况。

当相应的 iOS 实现（使用 CommonCryptor，iOS 5.1）在解码数据包时未能解码除第一个块之外的每个块时，我有点惊讶。似乎 CommonCryptor 以其他方式定义了计数器。CommonCryptor 可以在 big endian 和 little endian 模式下创建，但 CommonCryptor 代码中的一些模糊注释表明这不（或至少尚未）完全支持：

通过逐块解码，每次按照上面指定的方式设置 IV，它都能很好地工作。

我的问题：在一次解码多个块时，是否有一种“正确”的方式来实现 CTR/IV 模式，或者在使用不同的加密库时我是否可以期望它是互操作性问题？CommonCrypto 在这方面是否存在问题，还是只是以不同方式实现 CTR 模式的问题？

我知道在 AES 计数器模式下我需要使用 128 位随机数。天真的方法是使用随机的 128 位随机数，但我不确定如果将计数器作为所有随机位传递，算法是否能够正确递增计数器。我认为正确的方法是使用 96 位随机数和从 0 开始的 32 位计数器，例如：

这是使用CryptoJS 库的正确方法吗？或者正确的方法是什么？

是否可以在 AES/CTR 中解密加密视频并在解密时观看？

我想解密 MEGA.co.nz 上托管的视频，然后继续观看，而无需等待下载完成。

我已经知道如何解密了，只需要在视频中逐渐知道如何做到这一点

当我尝试使用相同的密钥再次加密密文时，它会产生原始明文。

使用的算法是带有COUNTER MODE的AES。Key和IV保持不变。

这是算法应该表现的方式吗？如果，作为Cipher.init () 的第一个参数给出的Cipher.ENCRYTMODE有什么用？

这是我测试的示例程序，

因此，在pyDes（DES 的加密库）中，有一个 API，如下所示pyDes.des(key, [mode], [IV], [pad], [padmode])。它的用法是这样的k = des("DESCRYPT", CBC, "\0\0\0\0\0\0\0\0", pad=None, padmode=PAD_PKCS5)——我可以使用 CBC 或 ECB 加密模式。但是，作为教授的任务，我被告知使用 pyDes 库进行加密，但手动使用 CBC 和计数器模式。

我设法很好地完成了 CBC 模式，不幸的是我被计数器模式卡住了。使用给定的 api 时，des(key, CBC, IV ...)我只能在使用 CBC 或 ECB 操作模式时使用 IV。我不能像des("hello", mode = None, "foo",....)“foo”是我的 IV 那样使用它。（我应该实现 Counter 操作模式，并且 iv 在每次迭代中都是随机的）所以，我的问题是有人遇到过这个问题，并试图克服它。

我有一个 1MB 的测试文件，我想从 500KB 开始解密它，而不是从头开始。它不需要完全从文件的 500KB 开始，它可以从任何块的开头开始，只要它不是第一个，我只是想学习如何去做。

有了这个脚本，我就可以解密文件，只要它从 0KB 开始。

如果至少有可能，有人可以解释一下吗？

我正在尝试使用 Crypto++ 在 ECB 模式（但仍然）之上手动制作 CTR。这个想法是：

对于单个块：只需使用 ECB 对于多个块，使用 CTR 算法（AFAIK）：

//我的xor()对两个char数组进行异或

测试 1：100% Crypto++ CTR

测试 2：基于 ECB 的手动 CTR

这是测试的主要内容：

auto_result 是：

"Yž+eÞsÂÙ\bü´\x1a¨Ü_ÙR•L¸Ð€¦å«ÎÍÊ[w®Ÿg\fT½\ý7!p\r^ÍdžúP\bîT\x3\x1cZï.s%\x1ei{ÚMˆØ… Pä¾õ\x46\r5\tâýï‚ú\x16ç'Qiæ²\x15š€á^ªê]W ÊNqdŒ¥ ^†¾j%8.Ìù\x6Þ›ÔÏ'[c\x19"

manual_result 是：

"Yž+eÞsÂÙ\bü´\x1a¨Ü_Ù·\x18ýuù\n\nl\x11Á\x19À†Žaðƒºñ®GäþŽá•\x11ÇYœf+^Q\x1a\x13B³'QQµºëÑÌåM\"\x12\x115â\x10¿Ô„›s °‰=\x18*\x1c:²IF'n@ŠŠ¾mGÂzõžÀ\x1eÏ\SëYU¼í'" >

我的工具有什么问题？

关于我的实施的信息

下面的代码片段突出显示了我当前使用 AES 密码和 CTR 操作模式实现的加密对象。

就我而言，getInstance()方法从支持此转换的第一个 Provider 返回一个实现所请求转换的 Cipher 对象。

接下来，有一个包含我所有可用提供者的列表：

即使我没有看到任何支持“ AES/CTR/NoPadding ”算法的提供程序， execute()方法也没有抛出NoSuchAlgorithmException，因此我想这个算法是由以前的提供程序之一支持的。

问题

• 之前哪个提供者被调用来获取支持“ AES/CTR/NoPadding ”算法的设想密码对象？

笔记

提供者列表太长，不适合这篇文章，如果您需要有关未提及的特定提供者的任何信息，请告诉我。

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

1. 128 位随机数与m位计数器值（通常为 32 位）进行异或。
2. 64 位随机数附加到 64 位计数器。

我的问题是：

• 关于 javax.crypto.Cipher 的“ AES/CTR/NoPadding ”实例中使用的初始计数器块的确切过程是什么（假设 SunJCE 作为提供者）？也就是说，给定上面的代码，如果有的话，使用了之前的初始计数器块方法中的哪一种？