Java Bouncy Castle在解密時總是拋出異常純文本

我的系統中有一個進程可以接收隨機純文本或密文輸入。由於性能是不是一個問題，我打算嘗試解密所有進入的輸入，用僞代碼是這樣的：Java Bouncy Castle在解密時總是拋出異常純文本

//get the input, either a plain text, or cipher text 'in disguise' 
//ex of plain text: "some text".getBytes() 
byte[] plainText = getInput(); 
try { 

    //try to decrypt whatever it is. Using Bouncy Castle as the AES crypto engine 
    plainText = AESDecryptor.decrypt(HARDCODED_AES_KEY, plainText); 
} catch(Exception ex) { 
    ... 
} 

//do some process with the plain text 
process(plainText);

我使用AES的加密方法。

上面的代碼在很大程度上依賴於假設試圖使用彈性城堡來解密純文本將始終拋出異常。但是假設100％正確嗎？當嘗試解密普通的，人類可讀的文本時，它總是會拋出異常嗎？

在此先感謝！

來源

2012-08-30 riza

簡短的回答

不，你不能保證一個例外。

較長答案

接收異常的概率是依賴於所使用的填充方案。當加密庫使用包含填充的算法解密數據時，它希望找到正確填充的明文。如果填充格式不正確（例如，因爲輸入是純文本而不是密文），則可能會拋出異常。

如果您的解密中沒有使用填充方案，並且您的輸入是密碼塊大小的倍數（在AES的情況下爲16字節），那麼您的圖書館將愉快地解密明文併爲您提供垃圾。

作爲示例，考慮PKCS #7 padding。這會在明文末尾附加非零的字節數，其值等於填充字節數。添加足夠的字節以將明文與密碼的塊大小對齊。例如：

12 34 56 78 9A BC DE F0 08 08 08 08 08 08 08 08

凡08值是八個字節的填充與AES的塊大小對準。所以，如果你解密一些明文，它可能會導致有效的填充？可能不會。但它可能，所以這是一個馬虎的方式來設計你的系統。

您需要在提議的協議中添加另一個圖層以指示數據是否已加密。此時指定使用的算法也可能很有用，因爲這可能會使您在將來更靈活地支持其他算法。

來源

2012-08-30 14:12:47

謝謝你的回答。如果你不介意，我可以作爲參考的任何鏈接嗎？ – riza

爲了清楚地識別有效的密文，我會在OCB或GCM模式下使用加密。 – Robert

@riza恐怕我沒有提及手;這個答案是基於我在應用程序安全領域工作的經驗。如果你在互聯網上研究填充，你會理解我的觀點。請注意，我也對BouncyCastle如何處理格式錯誤的填充做出了假設，但說實話，如果它不拋出異常（或返回'null'或其他），則不值得使用。 –

Java Bouncy Castle在解密時總是拋出異常純文本

回答

相關問題