AES中的差異填充異常

我正在開發一個項目，我需要向用戶發送驗證鏈接。所以使用AES加密來加密他的用戶名。我的代碼工作正常，即加密和解密工作正常，但只在程序中，當我測試它。我加密了一個字符串，然後解密它。它在當地很好地工作。AES中的差異填充異常

的問題是，當我發送電子郵件激活鏈接，點擊它，它給我的錯誤：

javax.crypto.BadPaddingException: Given final block not properly padded

我的代碼如下所示：

public class AES { 

private static final String algo="AES"; 
private static final byte[] keyValue= 
     new byte[]{somekey}; 

private static Key generateKey() throws Exception{ 

    Key key= new SecretKeySpec(keyValue, algo); 

    return key; 
} 

public static String encrypt(String email) throws Exception{ 

    Key key=generateKey(); 
    Cipher c=Cipher.getInstance(algo); 
    c.init(Cipher.ENCRYPT_MODE, key); 
    byte[] encVal=c.doFinal(email.getBytes()); 
    String encryptedEmail= new BASE64Encoder().encode(encVal); 

    return encryptedEmail; 
} 

public static String decrypt(String encryptedEmail) throws Exception{ 

    Key key=generateKey(); 
    Cipher c=Cipher.getInstance(algo); 
    c.init(Cipher.DECRYPT_MODE, key); 

    byte[] decodeEmail= new BASE64Decoder().decodeBuffer(encryptedEmail); 
    byte[] decodedEmail=c.doFinal(decodeEmail); 

    String decryptedEmail= new String(decodedEmail); 

    return decryptedEmail; 
    }

}

來源

2012-07-21 kunal18

有沒有人會幫助我？請緊急！ – kunal18 2012-07-21 09:37:02

無論何時出現任何錯誤的算法輸入（在您的案例中爲密鑰或密文），都會拋出BadPaddingException。您是否比較了基礎64編碼/解碼的輸出？您不應該使用內部Sun類，而應嘗試使用Bouncy Castle或Apache庫。 – 2012-07-21 10:31:00

你解決了這個問題嗎？如果是這樣，你能指出做了什麼並且接受或發佈了答案嗎？ – 2012-07-30 00:11:15

我使用Bouncy Castle庫的Base64編碼器/解碼器運行，完全沒有問題。檢查您的輸入/輸出，並使用有效的base 64編碼器/解碼器，而不是具有未指定輸入/輸出的Sun內置輸入/輸出。

警告：當您使用未指定的字符編碼時，它將使用平臺特定的一種，因此您的輸入/輸出可能在不同的系統上有所不同。嘗試並使用Charset.forName（「UTF8」）進行最兼容的字符編碼（在String構造函數和toBytes方法中）。

來源

2012-07-21 10:41:21

我會將字符編碼作爲問題下注。 – 2012-07-21 14:00:00

@GregS也許，它可能是base64字符串沒有被正確地轉換，否則轉換可能會失敗，但這將*解密後* – 2012-07-21 17:42:54

您的代碼在加密或解密時似乎沒有設置填充。明確地在兩端設置填充比較好。你也似乎沒有設置一個模式，也需要明確地完成。

我建議「AES/CBC/PKCS5Padding」作爲一個明顯的選擇。

來源

2012-07-21 09:53:23 rossum

所有這一切都是非常正確的，但由於默認情況下使用AES/ECB/PKCS5Padding，因此不構成答案。 – 2012-07-21 10:34:35

ECB模式不安全，避免它。 CBC或CTR是安全的。如果您想要驗證，請使用GCM。最好不要依靠違約，它可能會導致錯誤。接收端的默認值是什麼？ – rossum 2012-07-21 11:13:28

我認爲接收端包含在代碼中（指定了加密和解密）;問題是代碼實際上工作正常。注意：我不是問題的作者。 – 2012-07-21 11:17:57

AES中的差異填充異常

回答

相關問題