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

Difference between revisions of "Talk:Using the Java Cryptographic Extensions"

From OWASP
Jump to: navigation, search
(→‎AES mode on this page is insecure: new section)
(Some needed fixes to OWASP wiki page "Using Java Cryptographic Extensions")
 
Line 9: Line 9:
  
 
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.
 
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
 +
to
 +
        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.
 +
 +
-kevin

Latest revision as of 01:06, 18 March 2017

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

to 

       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.

-kevin

Retrieved from "https://wiki.owasp.org/index.php?title=Talk:Using_the_Java_Cryptographic_Extensions&oldid=227602"