2

If I generate a message digest (for a security feature in my app) using this Java code:

java.security.MessageDigest saltDigest = MessageDigest.getInstance("SHA-256");
saltDigest.update(UUID.randomUUID().toString().getBytes("UTF-8"));
String digest = String.valueOf(Hex.encode(saltDigest.digest()));

I end up with a really long string like the following:

29bcf49cbd57bbc41e601b399a93218ef99c6e36bae3598b5a5a64ac66d9c254

Not the nicest thing to pass on a URL!

Is there a way to shorten this?

arezzo
  • 2,915
  • 2
  • 15
  • 14
  • You could use Base64 instead of simple Hex encoding. That should save a few characters. – Joachim Sauer Sep 26 '11 at 15:15
  • True, thanks. I forgot about looking at the other classes in that package: http://static.springsource.org/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/core/codec/package-summary.html I wonder how much Base64 would impact how "secure" the digest is. If it's really only a question of a few characters, I guess probably not that much. – arezzo Sep 26 '11 at 15:18
  • since Base64 and Hex encoding represent the exact same information, the security of the content would be unaffected. *However* if some automated tool tries to handle your value, then it probably expects it to always be in the same format. – Joachim Sauer Sep 26 '11 at 15:19
  • Ok, I see. Well this is just information that's being passed around in URLs and HTML form posts in a Spring MVC app. So there are no automated tools that rely on a particular format. It's just going to be used in database lookups in combination with a PK to ensure that only people with valid privileges can modify entities. Whether this is a good idea or not is another question. But I understand your point about how Hex & Base64 don't alter the underlying content. – arezzo Sep 26 '11 at 15:23

1 Answers1

2

Well, that's the expected size of a SHA-256 hash, right? You could always do

String sha256 = yourSha256Calculation();
sha256.substring(0,10);

To get a shorter string, but that would not be SHA-256. What are you really trying to achieve?

SHA-256 is not the shortest hash out there, look at http://www.fileformat.info/tool/hash.htm?text=hello for a comparison.

jornb87
  • 1,441
  • 10
  • 15
  • I see. Well, I'm trying to generate some unique value that can be associated with an entity (besides its primary key) to make it accessible only to those who have the digest value. My idea was that it would be extremely unlikely for someone to have both the digest value and the pk by chance - although they might have one or the other by chance. – arezzo Sep 26 '11 at 15:15
  • What kind of output would you like? Is it the length of the string that is the problem? What about a smaller hash size, like MD5 or CRC? You can compare outputs here http://www.fileformat.info/tool/hash.htm?text=hello. – jornb87 Sep 26 '11 at 15:23
  • Dude! You rock. Awesome link. Exactly what I needed. Yeah, CRC might be fine. Thanks, man. – arezzo Sep 26 '11 at 15:31
  • @arezzo: Note that not all those hashes are secure. – Christoffer Hammarström Sep 26 '11 at 15:39
  • @Christoffer Hammarström: Thanks. You're right. I need to consider this. For security reasons I may not be able to afford a CRC32 hash since I am using the same calculation for my password hash. – arezzo Sep 26 '11 at 17:01
  • I don't quite understand your setup, but are you making a hash of the PK, or do you simply want to make a separate, unique string? If the hash is generated from the PK, then your hash should indeed be as safe as possible. If you want a short yet powerful hash, consider making your own hash (e.g. taking the CRC of the SHA256 of your input with an added salt, or whathever you want). This function must be unknown to the public. – jornb87 Sep 26 '11 at 17:38