拋出異常：寫入訪問衝突。這是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

回答

相關問題