问题标签 [cbc-mode]

我已经给出了初始化向量和输入文本。我也有编码的文本。

现在我的问题是，我怎样才能找到密钥，因为我的任务是更改输出文本。（这是一个家庭作业，我的教授说你可以在回家的路上在火车上半小时内完成......但我完全不知道，只知道 AES 和 CBC 是如何工作的，但绝对不是我必须如何开始这个任务。

任务：前 16 个字节是初始化向量，后 16 个字节是我的密文。我的文字是“向卡尔发送 5 美元”。现在我认为我首先需要关键因为我的任务是将消息“向卡尔发送 5 美元”更改为“向鲍勃发送 50 美元。

I'm trying to replicate a Java-based encryption scheme in Node.js but unfortunately I'm getting inconsistent results.

Here's the Java method:

And my Node version:

When I pass both functions the string "SomeJSON" and the same key I get different encrypted results.

From Java: ENnQzWowzrl7LQchRmL7sA== From Node: TGreJNmQH92gHb1bSy4xAA==

I can't figure out what is different in my Node implementation.

考虑以下 C++ 代码片段：

我在这里所做的是使用 openssl aes 库加密然后解密消息。我关心的是长度加密输出。据我了解，由于 AES 以大小为 AES_BLOCK_SIZE（又名 16 字节）的块进行加密，因此输出字节数应等于消息的大小，四舍五入为最接近的 AES_BLOCK_SIZE 倍数。这个对吗？特别是，如果我将消息扩展为正好 32 个字节长，会发生什么？这仍然有效，还是会添加 16 个空填充字节，从而在尝试在加密输出中写入字节 32 到 47 时导致分段错误？

Comments on https://gist.github.com/shadowhand/873637 state

"ECB mode encryption is a relatively simple method of encryption that provides a high level of obfuscation (or a low level of encryption). This method is not very secure and should not be used for sensitive personal data, but would work well for eg. transmitting source code between private parties in a public channel. For better security, you can switch the mode to CBC at the cost of having every file change completely for every modification. As with all encryption, a strong key is always recommended."

and

"This is kind of (part of) the definition of functionally correct encryption - ECB (click here for an explanation) is a flawed legacy implementation recommended by precisely nobody for current use today, and only supported in OpenSSL because OpenSSL supports some very old and creaky legacy crypto implementations! It's only useful today as a learning tool and should never be used in current systems.

CBC of OFB modes should be the default - please consider changing your gist to use CBC and explain the potential benefits of ECB along with the downsides for those who would like to accept the loss in security for slight convenience in git. Nothing should be insecure by default!"

http://git.661346.n2.nabble.com/Transparently-encrypt-repository-contents-with-GPG-td2470145.html however states that using a fixed-valued salt for CBC is bad crypto practice. If we switched the mode to CBC (for https://gist.github.com/shadowhand/873637 or https://github.com/shadowhand/git-encrypt), would it be using a fixed-value salt, and therefore be bad crypto practice?

(I've also posted this question as a comment on https://gist.github.com/shadowhand/873637 )

我正在尝试使用 glibc cbc_crypt 函数来加密 c 中的字符串，程序应该与函数一样可移植，这就是我使用这个库的原因

这是我的代码：

当我尝试运行该程序时，我得到以下信息：

我的目标是加密文件和解密文件，我愿意使用其他加密功能，但我需要这个程序是可移植的（我宁愿不使用 openssl，因为我的机器在没有那个库的情况下运行）

这是我的代码：

此脚本仅加密给定文件的第一行。如果我将加密更改为解密，它只会解密给定文件的一行。如何改变这一点，加密整个文件。

我加密了一条消息，然后通过套接字将其发送到其他计算机。但是我无法解密密文。我在两台计算机上使用了相同的密钥和 iv。我尝试将密文发送到其他计算机，然后将密文发回。我可以在同一台计算机上解密密文。但我想在其他计算机上删除它。这是我的代码。

I am looking for any clues as to how I can achieve cipher blocking chaining in RPGLE as I wish to encrypt data than is larger than 16 bytes. My understanding is that this is a necessity for AES to ensure it is split into only 16 byte blocks.

I am using the Qc3EncryptData() API

我在标准 ecb 模式下使用荨麻的 twofish 没有问题，但是我不确定这种 cbc 模式有什么问题？解密的消息将与原始消息不匹配。（使用一些硬编码的值，如 iv 仅用于测试目的）。

https://www.lysator.liu.se/~nisse/nettle/nettle.html

当我通过任何操作密码模式发送时，如何防止较长消息的加密块不会交换？那么收到后消息的含义不会改变吗？