抛出异常：写入访问冲突。这是0xDDDDDDDD

我试图加密使用加密++库API，版本5.6.0提供AES加密的字符串，静态抛出异常：写入访问冲突。这是0xDDDDDDDD

string AESEncryptor::encrypt(const string& plain) 
{ 
    string ciphertext_buffer; 

    // Hex decode symmetric key: 
    HexDecoder decoder; 
    decoder.Put((byte *)PRIVATE_KEY, 32 * 2); 
    decoder.MessageEnd(); 
    word64 size = decoder.MaxRetrievable(); 
    char *decoded_key = new char[size]; 
    decoder.Get(reinterpret_cast<byte*>(decoded_key), size); 

    // Generate Cipher, Key, and CBC 
    byte key[AES::MAX_KEYLENGTH], iv[AES::BLOCKSIZE]; 
    StringSource(reinterpret_cast<const char *>(decoded_key), true, 
     new HashFilter(*(new SHA256), new ArraySink(key, AES::MAX_KEYLENGTH))); 
    memset(iv, 0x00, AES::BLOCKSIZE); 

    CBC_Mode<AES>::Encryption Encryptor(key, sizeof(key), iv); 
    StringSource(plain, true, 
     new StreamTransformationFilter(Encryptor, new HexEncoder(new StringSink(ciphertext_buffer)))); 
    return ciphertext_buffer; 
}

挂在我收到以下异常的函数退出，同时努力调用std :: string移动构造函数返回值：

抛出异常：写入访问冲突。这是0xDDDDDDDD。

活像StringSink“拥有”返回的std :: string某种方式并试图恢复之前删除它，但是我试图把它分配给其他的std :: string，并得到了同样的异常。而返回其他任何字符串出现

同样的异常，因此它似乎内存崩溃某种程度上

来源

2016-09-20 user1750810

该文档明确指出StringSink不拥有输出字符串。 –

StringSource(plain, true, 
    new StreamTransformationFilter(Encryptor, 
     new HexEncoder(new StringSink(ciphertext_buffer)))); 

return ciphertext_buffer;

该代码主要是OK，但你应该避免匿名声明。

Exception thrown: write access violation. this was 0xDDDDDDDD.

0xDDDDDDDD is the "dead memory" bit pattern 有相当的代码的几个问题，它很难说这是造成你使用死者的记忆。也许PRIVATE_KEY小于32 * 2字节？

你应该做四两件事：

升级到Crypto++ 5.6.4（5.6.0从2009）
打开内存标志检查像_CRTDBG_LEAK_CHECK_DF（见test.cpp and main为例）使用
停止匿名声明（我见过破坏者因为他们而跑得太快）
使用EAX Mode来自Crypto++ wiki的示例代码作为起点

// Generate Cipher, Key, and CBC 
byte key[AES::MAX_KEYLENGTH], iv[AES::BLOCKSIZE]; 
StringSource(reinterpret_cast<const char *>(decoded_key), true, 
    new HashFilter(*(new SHA256), new ArraySink(key, AES::MAX_KEYLENGTH)));

使用HKDF从加密++ 5.6.3及以上。

memset(iv, 0x00, AES::BLOCKSIZE);

我相信这会破坏一些CBC的安全性能。您应该使用Authenticated Encryption模式。它可以减轻你的一些细节，比如生成随机IV。与CBC相比，它还具有更好的安全特性。

来源

2016-09-20 15:13:45 jww

我们可以质疑是否应该读取CBC安全属性的“一些”或“大部分” - 但绝对总是使用零的IV是一个禁忌。特别是，这意味着如果两个明文具有相同的第一个块，那么密文的第一个块也将相同 - 这对于攻击者从中获取有意义的信息可能绰绰有余。 –

迁移到Crypto ++ 5.6.4和新的API帮助，谢谢 – user1750810

抛出异常：写入访问冲突。这是0xDDDDDDDD

回答

相关问题