On an Android 4.4 device, a string has been encrypted using the org.springframework.security.crypto.encrypt.AndroidEncryptors class from the spring-android-auth 1.0.1.RELEASE module. So for example...
// naturally, salt and password are normally different
String salt = "75f4c92894b2f3e7";
String password = "password";
org.springframework.security.crypto.encrypt.TextEncryptor encryptor = org.springframework.security.crypto.encrypt.AndroidEncryptors.text(password, salt);
String encryptedString = encryptor.encrypt("hello");
During one run, the encryptedString resolved to "1ee3c42c9b986d30cd88da37f29bc3b9e93e3defdb76a2b23 72a47276152e2bd".
This string was then posted to a spring web application, hosted on tomcat 7 server, running on JDK 1.6.0_32 (note please that the JCE Unlimited Strength Jurisdiction Policy Files have been installed). I then attempt to decrypt that string using the org.springframework.security.crypto.encrypt.Encryptors class from the spring-security-crypto 3.2.0.RELEASE module...
// naturally, the salt and password values used here are the same as the ones used on the android device
String salt = "75f4c92894b2f3e7";
String password = "password";
org.springframework.security.crypto.encrypt.TextEncryptor encryptor = org.springframework.security.crypto.encrypt.Encryptors.text(password, salt);
String decryptedString = encryptor.decrypt("1ee3c42c9b986d30cd88da37f29bc3b9e93e3defdb76a2b2372a47276152e2bd");
Unfortunately, when the decrypt method is called the following exception is raised...
java.lang.IllegalStateException: Unable to invoke Cipher due to bad padding
at org.springframework.security.crypto.encrypt.CipherUtils.doFinal(CipherUtils.java:125)
at org.springframework.security.crypto.encrypt.AesBytesEncryptor.decrypt(AesBytesEncryptor.java:75)
at org.springframework.security.crypto.encrypt.HexEncodingTextEncryptor.decrypt(HexEncodingTextEncryptor.java:40)
at local.encryption.Decryption.main(Decryption.java:18)
Caused by: javax.crypto.BadPaddingException: Given final block not properly padded
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.AESCipher.engineDoFinal(DashoA13*..)
at javax.crypto.Cipher.doFinal(DashoA13*..)
at org.springframework.security.crypto.encrypt.CipherUtils.doFinal(CipherUtils.java:121)
... 3 more
If I encrypt and decrypt the string on the server, everything works correctly. This seems to suggest that AndroidEncryptor and Encryptor classes are not using the same algorithm, even though the API's say that they both use a 256 bit AES algorithm and that they both derives the secret key using PKCS #5's PBKDF2 (Password-Based Key Derivation Function #2).
When I drilled down into the AndroidEncryptor class, I found that it uses the "PBEWITHSHA256AND256BITAES-CBC-BC" algorithm. The Encryptor class however, uses the "PBKDF2WithHmacSHA1" algorithm.
Does anyone have any suggestions as to a way forward?
on Android i'm using
compile group: 'org.springframework.security', name: 'spring-security-crypto', version: '3.1.0.RELEASE'
on Spring-Backend i'm using
compile "org.springframework.security:spring-security-core:4.2.3.RELEASE"
My Example for you looks like:
val password = "MY_PASSWORD"
val salt = KeyGenerators.string().generateKey()
val encryptor = Encryptors.text(password, salt)
val textToEncrypt = "kotlin-rocks"
val encryptedText = encryptor.encrypt(textToEncrypt)
val decryptor = Encryptors.text(password, salt)
val decryptedText = decryptor.decrypt(encryptedText)
println("Salt: \"" + salt + "\"")
println("Original text: \"" + textToEncrypt + "\"")
println("Encrypted text: \"" + encryptedText + "\"")
println("Decrypted text: \"" + decryptedText + "\"")
If you run the code on Android you will get the following random result:
Salt: "2578bfa1cb682f17"
Original text: "kotlin-rocks"
Encrypted text: "bdfdfff122accfadc0ad5449bb9c93ceedd2380b2e7f8cd19d2ce03daec4218e"
Decrypted text: "kotlin-rocks"
Now you have to send the salt and the encrypted text to the server. The server will use both of them and can now decrypt the password. The implementation of the cipher code can be the same.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With