2

I am trying to implement AES 256 bit encryption/decryption algorithm. I realize there are multiple modes for this algorithm.

https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html

Every implementation of the Java platform is required to support the following standard Cipher transformations with the keysizes in parentheses:
AES/CBC/NoPadding (128)
AES/CBC/PKCS5Padding (128)
AES/ECB/NoPadding (128)
AES/ECB/PKCS5Padding (128)
DES/CBC/NoPadding (56)
DES/CBC/PKCS5Padding (56)
DES/ECB/NoPadding (56)
DES/ECB/PKCS5Padding (56)
DESede/CBC/NoPadding (168)
DESede/CBC/PKCS5Padding (168)
DESede/ECB/NoPadding (168)
DESede/ECB/PKCS5Padding (168)
RSA/ECB/PKCS1Padding (1024, 2048)
RSA/ECB/OAEPWithSHA-1AndMGF1Padding (1024, 2048)
RSA/ECB/OAEPWithSHA-256AndMGF1Padding (1024, 2048)

However in above, I didn't find any mode which has 256 bit key. Am I mistaking anything?

Gaurang Shah
  • 11,764
  • 9
  • 74
  • 137
  • Not clear. Do you want to use the library or do you want to implement your AES? Also, Why do you need Java 8? – kelalaka Apr 13 '20 at 18:04
  • @kelalaka implement AES encryption Decryption for 256-bit key using Java Library. – Gaurang Shah Apr 13 '20 at 18:07
  • I wrote a short answer, that can be very long, indeed. Is something not clear, please indicate. – kelalaka Apr 13 '20 at 18:43
  • 1
    The documentation specifies **minimums**. All current Java versions implement more than the minimum and in particular implement AES with 192 and 256 bit keys as well as 128. – dave_thompson_085 Apr 13 '20 at 20:28

1 Answers1

2

AES is a 128-bit block cipher with 128, 196, and 256-bit key sizes. AES is primitive and that needs a mode of operation to become an encryption scheme. Every mode of operation accepts any key sizes and the mode of operations is not related to the key size.

To use any mode operation one needs to implement the AES then the mode of operation. One may need only the encryption or also decryption of AES depending on the mode of operation.

Some mode of operations

  • ECB forgets it is insecure, see the ECB penguin in Wikipedia.
  • CBC mode is vulnerable to padding oracle attacks if used in the server. The Nonce in CBC mode should be unique and unpredictable.
  • CTR mode converts a block cipher into a stream cipher and doesn't need decryption of AES. Only encryption implementation is enough. The nonce in CTR mode must be used only once per key otherwise the confidentiality fails due to the crib dragging attack.

All the above is an archaic mode of operations and they can only provide Confidentiality if properly used.

In modern Cryptography, we prefer Authenticated Encryption (with Associated Data) Mode like AES-GCM. These modes provide not only Confidentiality but also integrity and authentication.

In GCM mode, one must be careful about the IV/Nonce generation since GCM internally uses the CTR mode and that inherits the same problem with the CTR mode, so never use the same IV under the same key. One can solve this issue by using counter/LFSR or in a combined mode with random.

Also, the IV reuse in GCM may result in a catastrophic result of forgery.

For the IV reuse problem, there is another mode that is becoming a standard in the near future, the SIV mode; AES-GCM-SIV.

Java Cipher of Oracle and IBM has limited to 128-bit key sizes. That is why you see 128 over there. It was changed since 8u151 in 2017. OpenJDK or BouncyCastle is not limited.

kelalaka
  • 5,064
  • 5
  • 27
  • 44
  • Thanks I didn't get all. However now I understand. the number of bits mentioned is for block and has nothing to do with size of encryption.. So doesn't matter which mode I choose, I can use 256 bit key. correct me if I am wrong – Gaurang Shah Apr 13 '20 at 19:02
  • Well, [Java has limited to 128-bit key sizes](https://stackoverflow.com/q/6481627/1820553). That is why you see 128 over there. Yes, the mode of operations is not related to key size. Note that the block size has an effect, like GCM mode only defined for 128-bit block sizes. – kelalaka Apr 13 '20 at 19:26
  • 2
    Only Oracle and IBM builds (not OpenJDK) were subject the 'limited crypto policy' (max 128 bits), and only until 8u151 in 2017. Since then **256-bit is fine**, as correctly commented on the Q you link. If you do use GCM in Java note it combines ciphertext + tag into one 'blob' on the API, which differs from many if not most other APIs. – dave_thompson_085 Apr 13 '20 at 20:29
  • @dave_thompson_085 Thanks. Does this limited crypto policy is due to the US requirements? – kelalaka Apr 13 '20 at 20:49
  • 1
    It certainly was in the late 1990s when Sun originally added crypto to Java (other than signing, which was unrestricted, and vital to Java's run-from-the-net concept). In the years since, US legal restrictions have been loosened in several stages, especially for opensource software, which IIRC Java officially became during j7, so Oracle probably could have fixed this a few years earlier if they had been motivated to. – dave_thompson_085 Apr 14 '20 at 19:08