Talk:Using the Java Cryptographic Extensions
While performing AES encryption using SunJCE provider, I did not see usuage of the mode in the program provided. I have few questions: Do we really need to specify the mode when using AES? Does PaddingException happen with AES and how do we prevent the PaddingException?
Please let me know.
AES mode on this page is insecure
The example for AES did not specify a mode which results in the default of ECB mode in most JCE providers!! I fixed that line and commented, but this will need some other work as it is not providing any Initialization Vector (IV) to the AES encryption since it was using ECB mode originally (bad). Will try to fix this with a working example.
Some changes that need to be made
[Note: Originally shared by me with Jim Manico in a private email dated 7/25/2016.]
Major things wrong with this wiki page:
1) IV size does NOT depend on key size, but rather cipher block size
Minimally, need to change lines that say:
final int AES_KEYLENGTH = 128; // change this as desired for the security level you want byte iv = new byte[AES_KEYLENGTH / 8]; // Save the IV bytes or send it in plaintext with the encrypted data so you can decrypt the data later
final int AES_BLOCKSIZE = 128 // AES cipher block size, in bits byte iv = new byte[AES_BLOCKSIZE / 8]; // Save the IV bytes or send it in plaintext with the encrypted data so you can decrypt the data later
so that is not implied. Because if user wanted to use 256-bit AES key, the IV should still be 16 bytes, not 32 bytes.
Ideally, we should replace with a call Cipher.getBlockSize(), but that requires reordering of the steps after the call to Cipher.getInstance().
2) Also using PKCS7PADDING, which is not valid in Java so this would fail. Change to PKCS5Padding.
(PKCS7 padding is actually technically the correct padding name, but Java blew it and called it PKCS5 padding. Technically, PKCS5 padding only applies to ciphers with a with a cipher block size of 64-bits, not 128-bits, but both PKCS5 and PKCS7 padding act identically for block sizes <= 255 bits.)
Best is to rewrite the entire thing and use CCM which isn't prone to padding oracle attacks, but I may not have time to do that.
3) Not portable across OS;. Should use getBytes("UTF8") instead of just getBytes(). Doesn't really matter for ASCII
strings like the "Hello world..." examples here, but can matter if encrypting binary data.
4) Example foolishly assumes that the IV doesn't need to be passed back and forth. In this particular case,
it doesn't, but in general it will. Usually IV is prepended to raw ciphertext and that is passed around. But because of examples like this where that is not shown, I've seen an awful lot (too many!) shortcuts of people just hard-coding a fixed IV to use instead.