问题标签 [block-cipher]

我已经为Crypto++ v5.6.2 实现了一个 C++ 包装库，并且对对称算法（例如 Blowfish）和块模式（例如 GCM）的组合有疑问。

我可以通过 Blowfish/EAX 加密和解密数据，但使用 Blowfish/GCM 无法达到同样的效果。AES/EAX 和 AES/GCM 都可以工作。

以下简单的应用程序演示了我的问题：

如果CryptoPP::InvalidArgument使用以下文本运行上面的代码，则会引发异常：

但是当使用块模式 EAX 运行代码时，不会引发异常。所以我的问题是：

• GCM 是否仅适用于 AES？GCM 也可以与 Blowfish 或 3DES 一起使用吗？
• 是否有可用的矩阵列出对称算法与块模式的所有可能组合？
• 或者这是 Crypto++ 中的一个错误？因为该方法BlockSize() 总是返回0，但只有在使用 Blowfish（或 3DES）而不是 AES 时才会引发异常。这似乎引发了提到的异常。

我得到了这个十六进制字符串中的密钥："140b41b22a29beb4061bda66b6747e14"并要求用实现 ECB 的 AES 解密一个分组密码。

我们知道，密钥必须是 16 个字节长。但是给定的键包含对应于大于一个字节的字符的元素（例如0xb2，其 char 值²对应于 2 个字节）。

事实上，如果我将十六进制字符串键转换为我获得的键字符串" A²*)¾´Úf¶t~ "，那么如果我应用该方法key.getBytes().length，我得到的是键长 21 个字节。

我的问题是：在 Java 中给定这个密钥，有什么方法可以用 AES 加密 16 字节长的密文？

我用java编写了这段代码来解密密文。我有钥匙。一切对我来说似乎都是正确的，但我有我要解释的问题。
这是我的代码：

我收到以下错误：

出了什么问题？我知道这个问题在某种程度上与填充有关，但我没有确切的解决方案。我只有一个密文、IV 和密钥。

首先让我说我是加密领域的新手。话虽如此，我正在开发一个应用程序，需要将用户名、密码和全名（名字、中间名、姓氏）加密存储在数据库表中。我正在阅读一篇文章，IV 对于发生的每个加密应该是随机的，并且我可以将 IV 添加到密文中。

这就是令人困惑的地方。如果我在字符串前面加上文本，我将如何解密字符串，除非我确切知道 IV 结束和密文开始在字符串中的哪个位置？另外，我在读到我应该在实际加密之前通过附加或前置附加文本来加盐字符串。IE，我创建的一些字符串并将其添加到明文中，我对加盐的理解是否正确？

如果我将加密的用户名和密码存储在数据库中，当我需要对用户进行身份验证时，我是否应该担心任何问题。我可以在用户输入字段后可靠地加密用户名和密码，然后将加密值与数据库中的加密列进行比较吗？似乎这将是一个问题，如果是这样，推荐的处理方法是什么？

我不是加密专家，所以我对这些事情的了解几乎为零。我必须与使用 RSA 加密的系统进行互操作。使用他们的密钥时，我遇到了为相同的输入/密钥获取不同密码的问题。该库是https://code.google.com/p/pajhome/source/browse/trunk/crypt/md5/rsa/RSA.js?r=133，我正在使用 Java BouncyCastle RSA Provider，如下所示：

我正在使用 Bouncy Castle 库来加密我的 Windows 应用商店应用程序中的一些数据。我的EncryptHelper班级：

我的Process()方法工作正常，但在指示时

如果流有太多数据，我担心它可能会发生 OutOfMemoryException。因此，我试图构建该ProcessBlocks()方法，该方法应逐步从流中读取，每次一个块，而不会对 RAM 过度充电。我对如何处理有一些疑问outBuffer：它应该在执行 cipher.ProcessBytes() 的每个周期中被覆盖，但是在the cipher.DoFinal()调用之前它应该是什么大小？

谢谢

2015 年 7 月 30 日更新

我修改了答案中的 Main 来处理一个 zip 文件，而输出的 zip 文件不再是一个有效的 ZIP，有人能解释一下为什么吗？

我正在使用 ECB 密码模式和 Threefish 对称分组密码在 .NET 中加密和解密字符串，我已将其实现作为 .dll 附加到我的项目中这是 .NET 实现的链接

密钥大小等于块大小，在我的例子中是 256 位。

问题是，据我了解，输入字符串明文的长度必须等于密文的长度。还是必须的？例如，在我的例子中，考虑到 ASCII 编码，明文被分成块，每个块包含 32 个字符，但每个块总是有 12 个额外的密文字符，正如我已经弄清楚的那样！即密文长度=初始文本长度+12*n，其中n为文本块数，即str.Length/32（str-初始字符串，已填充为32的倍数） .

我的代码（如下）是否有错误，或者我的理解是否仅适用于非常简单的分组密码，仅使用 XOR 操作进行加密，而对于复杂的 .NET 加密系统，此规则不满足？如果是后者，请解释一下是什么让这些长度不同！！！先感谢您。

我想知道以加密形式存储的数据是通过块密码还是流密码加密的？

我有加密数据，如何检查它来自块密码还是流密码？

我的公司正在开展一个将读卡器投入现场的项目。读卡器使用 DUKPT TripleDES 加密，因此我们需要开发软件来解密我们服务器上的卡数据。

我刚刚开始触及这个问题的表面，但我发现自己陷入了一个看似简单的问题……在尝试生成 IPEK（重新创建对称密钥的第一步）时。

IPEK 是通过连接两个三重 DES 加密的 8 字节十六进制字符串创建的 16 字节十六进制值。

我已经尝试过带填充和不带填充的 ECB 和 CBC（IV 为零）模式，但是当我需要与输入大小相同的结果时，每个单独编码的结果总是 16 字节或更多（2 个或更多块）。事实上，在整个过程中，密文应该与被编码的明文大小相同。

结果：3C65DEC44CC216A686B2481BECE788D197F730A72D4A8CDD

如果您使用 NoPadding 标志，则结果是：

3C65DEC44CC216A686B2481BECE788D1

我还尝试将纯文本十六进制消息编码为 base64（因为密钥是）。在上面的示例中，返回结果为：

DE5BCC68EB1B2E14CEC35EB22AF04EFC。

如果您这样做，除了使用 NoPadding 标志外，它会出现“输入长度不是 8 字节的倍数”的错误。

我是密码学的新手，所以希望我在这里犯了一些非常基本的错误。为什么这些分组密码算法生成的密文与明文消息的长度不同？

对于更多背景知识，作为“通过它工作”练习，我一直在尝试复制此处列出的工作：

https://www.parthenonsoftware.com/blog/how-to-decrypt-magnetic-stripe-scanner-data-with-dukpt/

我正在尝试编写一个可以使用分组密码加密和解密文本的 python 脚本，但我一直得到完全空白的输出。在尝试追查问题的根源后，我意识到在执行 XOR 位运算 (a^b) 后，我的脚本无法将新的 ascii 值转换为字符。

其中 rawkeylist 是将原始键转换为每个字符的 ascii 值（十进制）列表。而 textlist 是将文本转换为每个字符的十进制 ascii 值列表。我已经使用 print 来确认这些正在输出正确的列表。

问题是我尝试过的几个输入没有产生答案。更重要的是，通过将 print 替换到各个地方，我发现 str(unichr(element^rawkeylist[kli])) 在对 unichr 进行了一些研究后没有输出任何内容，我发现它实际上输出了 u'____' （带有 _____充当占位符）。

我不能将我的 ASCII 值转换回字符，但这似乎不是最具创新性的解决方案。我也非常怀疑使用字符串添加到我的答案的有效性。最后，我只是在应用密码时通过密钥的字符进行循环，在做了一些研究之后，我听说了一种我觉得我应该使用的叫做填充的东西。

所以嗯，请帮助我猜。