This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Talk:Using the Java Cryptographic Extensions

Revision as of 01:06, 18 March 2017 by Kevin W. Wall (talk | contribs) (Some needed fixes to OWASP wiki page "Using Java Cryptographic Extensions")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.