0

A defined key is used in this example:

byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09,
    0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");

I need to know what is the recommended approach to generate dynamic enhanced unpredictable key, especially when security working with JAX-WS , JAX-RS web services.

Duncan Jones
  • 67,400
  • 29
  • 193
  • 254
Kasun
  • 561
  • 11
  • 22
  • What do you think about UUID? – Braj Apr 06 '14 at 11:49
  • Read about [how good is java's UUID.randomUUID?](http://stackoverflow.com/questions/2513573/how-good-is-javas-uuid-randomuuid?answertab=votes#tab-top) – Braj Apr 06 '14 at 11:50
  • This generates random numbers. Security experts say it is a bad practices to use random numbers as security Reference keys.http://healthcaresecprivacy.blogspot.com.au/2012/02/bad-randon-number-generator-will.html – Kasun Apr 06 '14 at 11:54
  • Sorry, I don't have another idea? – Braj Apr 06 '14 at 11:55
  • Have a look at my answer, this will generate a 24-byte securely random key. It depends on your operating system how this happens - Java abstracts that away in a secure manner – Erwin Bolwidt Apr 06 '14 at 15:56

1 Answers1

1

That's what the SecureRandom class in Java is for:

SecureRandom random = new SecureRandom();
byte[] key = new byte[24]; // 24 or whatever your key length is
random.nextBytes(key);

SecureRandom provides a "a cryptographically strong random number generator (RNG)" according to the Javadoc documentation. It's often faulted for being slow, but not for being insecure.

Erwin Bolwidt
  • 30,799
  • 15
  • 56
  • 79
  • 1
    Well, I'd argue that the `KeyGenerator` class is for this purpose actually. – Duncan Jones Apr 06 '14 at 15:46
  • Two things: how do you think the `KeyGenerator` class gets is source of randomness? `SecureRandom`, indeed. Secondly, the example that the OP refers to, needs a byte[] `keyBytes`. – Erwin Bolwidt Apr 06 '14 at 15:53
  • 1
    The source of randomness depends upon the JCE provider. Using a `KeyGenerator` is the better approach as it's more portable (particularly if moving to an hardware security module). Secondly, the example doesn't require a `byte[]`, it needs a `SecretKey`. I think it's safe we can change a line or two in the original code. – Duncan Jones Apr 06 '14 at 15:56
  • SecureRandom is the platform standard way of generating secure random information. It *has* a provider architecture and it *uses* hardware security if available. – Erwin Bolwidt Apr 06 '14 at 15:58
  • 1
    Yes, but it results in key material exposed in memory. This does not happen when using a `KeyGenerator` implementation from an HSM provider. – Duncan Jones Apr 06 '14 at 16:00
  • Look at the Javadoc of KeyGenerator: ["There is also one that takes just a keysize argument, and uses the SecureRandom implementation of the highest-priority installed provider as the source of randomness (or a system-provided source of randomness if none of the installed providers supply a SecureRandom implementation), and one that takes just a source of randomness."](http://docs.oracle.com/javase/6/docs/api/javax/crypto/KeyGenerator.html) – Erwin Bolwidt Apr 06 '14 at 16:00
  • It does - KeyGenerator uses SecureRandom as per the specification. – Erwin Bolwidt Apr 06 '14 at 16:01
  • 1
    That Javadoc may accurately describe how some `KeyGenerator` implementations work, but it doesn't describe them all. Our two approaches are very similar, but what I'm suggesting is the correct way at it ports nicely over into situations where HSMs are used. – Duncan Jones Apr 06 '14 at 16:03