Rijndael support in Java

Question

We have a requirement to do some Rijndael development in Java.

Any recommendations for articles, libraries etc. that would help us?

Any pointers to keystore maintenance and how store the keys securely?

Edit:

It would need to be open source. Essentially, it's just standard encrypt / decrypt of data using Rijndael.

Wilds

Answer 1

Java includes AES out of the box. Rijndael is AES. You don't need any external libraries. You just need something like this:

byte[] sessionKey = null; //Where you get this from is beyond the scope of this post
byte[] iv = null ; //Ditto
byte[] plaintext = null; //Whatever you want to encrypt/decrypt
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
//You can use ENCRYPT_MODE or DECRYPT_MODE
cipher.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(sessionKey, "AES"), new IvParameterSpec(iv));
byte[] ciphertext = cipher.doFinal(plaintext);

And that's it, for encryption/decryption. If you are processing large amounts of data then you're better off reading chunks that are multiples of 16 bytes and calling update instead of doFinal (you just call doFinal on the last block).

Lipophilic

Rijndael isn't equal to AES, but instead is AES with some restrictions - fixed block size of 128 bits, and some crypto modes not supported. Any full AES implementation should be usable as Rijndael. – Calceolaria

This is exactly the reverse, AES is a subset of Rijndael – Thermotaxis

@BrunoRohée is correct. AES is a subset of Rijndael, check this #749122 – Chelsae

I don't want to edit my answer because these comments were made after it was selected as the right one, and I think 3 comments stating that AES is a subset of Rijndael should be enough for anyone to notice I got it backwards. – Lipophilic

what are the two values that you supply in the sessionKey & iv? from where you get them? – Cafeteria

both should be random – Lipophilic

Answer 2

For a great free library, I highly recommend BouncyCastle. It is actively maintained, high quality, and has a nice array of code examples. For reference documentation, you'll have to rely more on the general JCE docs.

I can't say what library we use to meet FIPS certification requirements. But there are alternatives to CryptoJ that are much, much cheaper.

In general, I'd recommend generating a new key for each message you encrypt with a symmetric cipher like Rijndael, and then encrypting that key with an asymmetric algorithm like RSA. These private keys can be stored in a password-protected, software-based key store like PKCS #12 or Java's "JKS", or, for better security, on "smart card" hardware token or other crypto hardware module.

Choosy

Answer 3

As my company recently found out, AES is not quite Rijndael. AES has the restriction that keys MUST be 128, 192, or 256 bit - however, Rijndael allows for keys that are 160 and 224 as well.

As indicated by erickson above, BouncyCastle provides a Rijndael object that DOES support the additional key lengths: 128/160/192/224/256 bits. Specifically, take a look at the lightweight API.

Gnu-crypto is another open source library - however, it also does NOT provide support for 160 and 224 bit keys.

So, if you are specifically looking for full Rijndael support, then BouncyCastle is the only one I've found so far.

Sibelle

If you need to use the java for android developement (although the question does not state that, it is worth noting that Bounty Castle has a brother now, that gives more flexibility on android known as Spongy Castle, which is a derivative.. and quite good actually) – Chelsae

Answer 4

javax.crypto has AES support: http://java.sun.com/developer/technicalArticles/Security/AES/AES_v1.html

As for secure key storage, the usual method is to derive an encryption key from user input (a passphrase) using a cryptographic hash function, and use the derived key to encrypt the keychain. Or, if you only need one key, you can use the derived key itself.

Always keep in mind that the security of the system is directly related to the strength of the hash function used. Use a cryptographically secure hash function, along with a salt if possible, and hash more than once (hundreds of times, for example).

That being said, the question is very vague.

Deaton

it is also worth noting that javax.crypto uses a very optimised version of AES and is quite fast. – Chelsae