I'm encrypting a GUID string with AES in .NET with the following code.
// Decode the challenge bytes from base 64
byte[] challengeBytes = Base64.decode(challenge, Base64.NO_WRAP);
ICryptoTransform encryptor = aes.CreateEncryptor(key, initializationVector);
MemoryStream memoryStream = new MemoryStream();
// Create a stream to encrypt our data
CryptoStream cryptoStream = new CryptoStream(memoryStream, encryptor, CryptoStreamMode.Write);
cryptoStream.Write(challenge, 0, challenge.Length);
cryptoStream.FlushFinalBlock();
byte[] encryptedChallengeBytes = memoryStream.ToArray();
// Clean up
memoryStream.Close();
cryptoStream.Close();
// Convert to a base 64 string
return Convert.ToBase64String(encryptedChallengeBytes, Base64FormattingOptions.None);
Then in Android I'm decrypting with the following code.
Cipher aes = Cipher.getInstance("AES/CBC/PKCS7Padding");
SecretKey key = new SecretKeySpec(keyBytes, "AES");
// Initialize the cipher
aes.init(Cipher.DECRYPT_MODE, key, new IvParameterSpec(initializationVector));
guid = new String(aes.doFinal(challengeBytes));
return guid;
I've done all sorts of debugging and IV, the Key and Challenge Bytes are exactly the same on both platforms. I've looked at them byte by byte and they're good. They only difference is that on .NET they range from 0-255 and on Android they range from -128 to 127. Now I'm not sure if that is the issue or not but I just assume that 2's complement shouldn't affect the Java implementation of the algorithm because that would just be stupid in my opinion.
I'm getting this exception when trying to decrypt
03-01 20:31:48.313 12886-12982/com.danielwardin.social I/SOCIAL﹕ eneter.messaging.messagingsystems.simplemessagingsystembase.internal.DefaultDuplexOutputChannel@2474079b
03-01 20:32:50.157 12886-12988/com.danielwardin.social W/System.err﹕ javax.crypto.BadPaddingException: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
03-01 20:32:50.158 12886-12988/com.danielwardin.social W/System.err﹕ at com.android.org.conscrypt.NativeCrypto.EVP_CipherFinal_ex(Native Method)
03-01 20:32:50.187 12886-12988/com.danielwardin.social W/System.err﹕ at com.android.org.conscrypt.OpenSSLCipher.doFinalInternal(OpenSSLCipher.java:430)
03-01 20:32:50.188 12886-12988/com.danielwardin.social W/System.err﹕ at com.android.org.conscrypt.OpenSSLCipher.engineDoFinal(OpenSSLCipher.java:466)
03-01 20:32:50.188 12886-12988/com.danielwardin.social W/System.err﹕ at javax.crypto.Cipher.doFinal(Cipher.java:1340)
This is the line causing the trouble
guid = new String(aes.doFinal(challengeBytes));
The challengebytes array is always 48 bytes which is a multiple of 16 as well so I have no idea why I'm getting the BadPaddingException
.
I've looked all over Google and tweaked it for around 4 hours and my brain is just dead now.
Any ideas?
PKCS7Padding is a padding scheme that always pads. When the plaintext is a multiple of the block length, then an additional block is added with each byte set to the value of the block length (modulo 256). This removes ambiguity: what if the last byte of the plain text was 01? It would look like 1 byte of padding and be stripped.
So just remove that from where you construct the cipher in Java, since you are not actually using a padding scheme:
Cipher aes = Cipher.getInstance("AES/CBC/NoPadding");
--Edit: Sorry, I mixed up the semantics. See more information here.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments