Home/ Questions/Q 7759701
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T13:41:57+00:00

I need to encrypt & decrypt data with both Java (on Android) and SJCL

  • 0

I need to encrypt & decrypt data with both Java (on Android) and SJCL (I could plausibly switch to another JS crypto library, but am familiar with SJCL so would prefer to stick with it if possible).

I have the SJCL end working fine, but at the Java end I’m not really sure what parameters I need to use to set up the key generator and cipher. The code I have so far for decryption is:

SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
KeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 1024, 256);
SecretKey tmp = factory.generateSecret(spec);
SecretKey secret = new SecretKeySpec(tmp.getEncoded(), "AES");

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.DECRYPT_MODE, secret, new IvParameterSpec(iv));
String plaintext = new String(cipher.doFinal(ciphertext), "UTF-8");
return plaintext;

Where salt, iv and ciphertext are extracted as strings from the JSON object produced by SJCL and then decoded using a Base64 decoder to byte arrays.

Unfortunately, I have a few problems with this and the code above doesn’t work.

The first problem I have is that PBKDF2WithHmacSHA256 doesn’t seem to be a recognised key generation algorithm. I’m not entirely sure that this is what I want, but it appears to be right based on reading the SJCL documentation? Java does recognise PBKDF2WithHmacSHA1, but this doesn’t seem to be the same algorithm SJCL implements.

Secondly, if I try using the SHA1 key algorithm, I get an error about invalid key size. Do I need to install something to enable AES with 256-bit keys? Telling the key factory to produce a 128-bit key works OK (although obviously is not compatible with SJCL, which is using a 256-bit key).

Thirdly, what cipher mode should I be using? I’m pretty sure CBC isn’t right… SJCL’s documentation mentions both CCM and OCB, but Java doesn’t seem to support either of these out of the box — again, do I need to install something to make this work? And which one does SJCL default to?

And finally, even if I pick parameters that make Java not complain about missing algorithms, it complains that the IV provided by decoding the SJCL output is the wrong length, which it certainly appears to be: there are 17 bytes in the resulting output, not 16 as is apparently required by AES. Do I just ignore the last byte?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I haven’t tried it (in the end I switched away from using Javascript crypto in favour of using an embedded java applet with bouncycastle to handle communication), but GnuCrypto (a bouncycastle fork) supports PBKDFWithHmacSHA256. The fixed character encoding handling in SJCL presumably fixes the unexpected length of the IV (?), so this would just leave the cipher mode. From this point, it appears that the easiest approach would be to implement a relatively simple cipher mode (e.g. CTR) as an add-on for SJCL, which ought to be only a few hours work even for someone unfamiliar with the code, after which it is simply a matter of encoding and decoding the JSON-encoded data packets that are used by SJCL (which ought to be trivial).

    As an alternative, it would certainly be possible to implement OCB mode for Java, despite the fact that the algorithm is proprietary, as there is a public patent grant for software distributed under the GPL (http://www.cs.ucdavis.edu/~rogaway/ocb/grant.htm).

    Interestingly, I wonder whether GnuCrypto would accept a patch for OCB mode support? GnuCrypto is distributed under GPL-with-libraries-exemption, which would appear to qualify as “any version of the GNU General Public License as published by the Free Software Foundation”, so theoretically at least this should be possible.

    • 0