c++ - 程序重新启动时文件不解密，使用相同的加密 key

Question

我有一个简单的程序，可以根据从文本文件获得的输入对文本进行加密和解密。当我在一个循环中加密和解密时，我得到了想要的结果，但是如果我加密，关闭应用程序然后重新运行应用程序，这次解密，过程失败。

解密片段如下所示:

string decoded, plainText;
string fileData((istreambuf_iterator<char>(fileDecrypt)), (istreambuf_iterator<char>()));

ECB_Mode<AES>::Decryption decryption;
decryption.SetKey((byte*)key.c_str(), sizeof(key));
StringSource(fileData, true, new HexDecoder(new StringSink(decoded)));
StringSource(decoded, true, new StreamTransformationFilter(decryption, new StringSink(plainText)));

当我在 VS2010 中运行调试器时，我在最后一行出现错误

StringSource(decoded, true, new StreamTransformationFilter(decryption, new StringSink(plainText)));

当我在 decrypt 函数周围包装一个 try-catch block 时，出现此错误

StreamTransformationFilter: invalid PKCS #7 block padding found

不知道为什么如果我在一个构建中加密和解密它会起作用，但如果我在同一次运行中没有先加密就尝试解密会失败。

Answer 1

ECB_Mode<AES>::Decryption decryption;

ECB 模式在完整 block 大小上运行，不需要填充。

你可以填充它，但它看起来不像你这样做。需要注意的是纯文本必须是 16 的倍数，这是 AES 的 block 大小。

---

When I wrap a try-catch block around decrypt function, I get this error

StreamTransformationFilter: invalid PKCS #7 block padding found

那是因为你在填充它:

StreamTransformationFilter(decryption, new StringSink(...)).

StreamTransformationFilter has a padding parameter .正如您可能意识到的那样，它是 BlockPaddingScheme::PKCS_PADDING

---

尝试:

ECB_Mode<AES>::Decryption decryption;
decryption.SetKey((byte*)key.data(), key.size());

std::string plainText;
StreamTransformationFilter filter(decryption, new StringSink(plainText),
                                  StreamTransformationFilter::NO_PADDING);

FileSource fs(filename.c_str(), true, new HexDecoder(new Redirector(filter)));
...

---

其他勘误表:

ECB_Mode<AES>::Decryption decryption;
decryption.SetKey((byte*)key.c_str(), sizeof(key));

sizeof(key) 是错误的。使用 16、24 或 32。如果 std::string 的大小合适，则可以使用 key.size()。

并为您的对象命名。我见过 GCC 使用 Crypto++ 生成错误代码:

ECB_Mode<AES>::Decryption decryption;
StringSource ss1(fileData, ...);
StringSource ss2(decoded, ...);

---

还有一个快速警告....

欧洲央行模式通常是错误的。我不是说在这种情况下是这样，或者你错了。但你可能想看看 EAX mode , GCM mode或 CCM mode .如果这比看起来更多，我深表歉意。

更好的是，使用类似 Elliptic Curve Integrated Encryption Scheme (ECIES) 的方案或 Discrete Logarithm Integrated Encryption Scheme (DLIES) .这些方案是 IND-CCA ，这是一个非常强大的安全概念。

当使用 ECIES 或 DLIES 时，您的问题减少到共享公钥。但是你现在遇到了对称 key 的问题，所以它是 key 分发的横向移动，也是加密的胜利。