Java crypto API vs. different platforms

I have an Android application, which uses javax.crypto to encrypt some text data in files. Encryption implementation is similar to this. The application works fine with the encrypted data it previously created.

Now, I almost ported my Android application to desktop (JFace/SWT). I'm using the same encryption implementation for the ported application, as it does not depend on any Android-specific API. The ported application works fine with encrypted data it created.

The problem is that desktop application cannot decrypt data, which was saved with Android application. The Android application fails to decrypt data, which was saved with desktop application as well. I double checked bytes streams of plain data and password to encrypt on both platforms. They are the same, so there are no problems with text encoding or so. But encryption routine return different encrypted results on different platforms even input data is byte-to-byte identical.

Does Java crypto API guarantees the same operation on different platforms? Should an encryption provider (AES/128bit in my case) work the same way on Android, Linux and Windows?开发者_运维知识库 Is there a way to tune javax.crypto to get interoperability on different platforms?

AES-128 should work the same on both systems. In theory.

In practice there are a lot of details that need to be the same on both systems.

• are you using the same padding at both sides?
• are you using the same mode (CBC, CTR, ECB) at both sides?
• do you have exactly the same password at both sides?
• do you have the same IV/Nonce at both sides?
• do you have the same key derivation method on both sides?

Check any defaults on both systems. If the defaults don't match then you will need to set one side or the other explicitly.

It is a mistake to depend on a cryptographically-random number generator generating the same random numbers on different platforms. Normally, the cryptographic random salt used in a key-derivation algorithm has to be communicated from sender to receiver. It might be communicated as a secret, but it does need to be communicated. The "master password" is the main secret, of course.

One way these salts are often communicated is as a prefix on the ciphertext. That makes the ciphertext longer than the plaintext, but I don't think that matters in your sample technique.

Also, for a full-up encrypted-message exchange, other parameters of the encryption need to be communicated to the decrypter. You can wire those into your implementations, as you've done here, but depending on reproducibility seems too brittle. It is of course something an attacker can replicate, of course, so it is not part of your secret.

You might want to rethink the key-generation algorithm setup to be something more robust.

Afterthought: What is happening in the current approach is a cryptographically-useful RNG is being used in a way where all the randomness has been removed! The recommendation to check out PBKDF2 and key-derivation generally is a good one.

You'd have to show us some code. One frequent beginner mistake is to store the encrypted data in a String rather than the byte[] it came in. String isn't a container for binary data. This technique can fail in many ways including default charade differences.