-1

Basically, I'm trying to hash a user specified string into a 256 bit byte array to be used as a key when encrypting data using Java's implementation of AES256. I keep getting this runtime exception: 

java.security.InvalidKeyException: Illegal key size or default parameters

I suspect it's because some of the bytes aren't 8 bits long, so the overall key size isn't 256 bits. I was wondering how to pad them out with 0's on the left, so ensure the length of the key?

EDIT:

This is the conversion from a value to a message digest: 

MessageDigest hasher = MessageDigest.getInstance("SHA-256");
// Use the factory method to get the SHA-256 instance of a MessageDigest object.
hasher.update(input.getBytes());
// Update the message digest object with the bytes of the value to hash.
return hasher.digest();
// Hash the value and return the string representation.

This is the encryption, using the output from "hasher".

SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
cryptoTool.init(Cipher.ENCRYPT_MODE, key); // This is where the error fires.

return String.valueOf(cryptoTool.doFinal(plaintext.getBytes()));
Duncan Jones
  • 67,400
  • 29
  • 193
  • 254
christopher
  • 26,815
  • 5
  • 55
  • 89
  • 1
    You can be sure that all bytes are 8 bits long in Java. – Axel Feb 14 '13 at 22:42
  • Okey doke. Well can you think of another reason why I might get an invalid key exception for the result of a SHA256 hash? – christopher Feb 14 '13 at 22:43
  • Can you provide your code? That would probably help us identify the problem. – Louis Wasserman Feb 14 '13 at 22:44
  • Could you post some working (or in this case: non-working) code? – Axel Feb 14 '13 at 22:44
  • 1
    Your key most likely isn't 256 bits (32 bytes). – FThompson Feb 14 '13 at 22:44
  • Where is the exception coming from--the hash generator, or a consumer of the hash? Also consider that characters in java are not a single byte like they are in C. And don't forget to check the "default parameters" half of the exception message. – Byron Hawkins Feb 14 '13 at 22:45
  • whats your key ? it should look look like this byte key[32]; – gheese Feb 14 '13 at 22:47
  • 1
    This is just the effect of not having the unlimited crypto files installed in your JRE. – Maarten Bodewes Feb 14 '13 at 22:51
  • The key is the message digest of a SHA256 hashing algorithm. It's the Java native hashing algorithm. I've checked it and the output is of length 32. But with PKCS5Padding set in the Ciper.getInstance() factory method, wouldn't that pad out the key for me, or is that just the plaintext? – christopher Feb 14 '13 at 22:52
  • @ChrisCooney that undoubtedly took longer than 49 secs to type in, otherwise you would have seen my comment :) – Maarten Bodewes Feb 14 '13 at 22:52
  • Apologies. I don't have the "unlimited crypto files" installed? Probably best to give an explanation for future readers :) – christopher Feb 14 '13 at 22:56
  • I've downvoted because I suspect a lack of research. The top [upteem search results](https://www.google.co.uk/search?q="Illegal+key+size+or+default+parameters") for your error will provide you with the answer. – Duncan Jones Feb 15 '13 at 07:43
  • @Vulcan No, that results in a [different error message](http://stackoverflow.com/questions/14885420/illegal-key-size-or-default-parameters/14885479#comment20881383_14885486). – Duncan Jones Feb 15 '13 at 08:32

1 Answers1

-1

I'm guessing maybe the String isn't 32 characters? Or you have a string that might contain non-ASCII characters?

The following function will take a string and produce a 32-byte array out of it.

String to32Bytes(String s) {
   return Arrays.copyOf(s.getBytes(), 32);
}

Note, this is a not a great way to do encryption, as a string hashing algorithm will in general provide a much more secure key.

Dave DeCaprio
  • 2,051
  • 17
  • 31
  • Of course this will also produce the first 256 bytes of the string in a platform-dependent encoding, which might not be the best idea for interoperability. When you're deriving keys from strings you should probably involve a fixed encoding and Unicode normalisation. – millimoose Feb 14 '13 at 22:48
  • Well the method I am using is the String Hashing Algorithm. Plus the string isn't going to be 256 characters, because it's 256 bits, which is 256/8 characters in ASCII. Thankyou for the suggestion, but surely it makes more sense to pursue the better method than it does to instantly settle for something less efficient. – christopher Feb 14 '13 at 22:49
  • The exception message given by the OP is *not* the result of the wrong key size. That would look like: `java.security.InvalidKeyException: Invalid AES key length: xx bytes`. – Duncan Jones Feb 15 '13 at 07:57