Advanced security questions

[Jake Arkinstall]

What if I used a raw binary hash?

Hex and binary go hand in hand.

Look at any decimal number - say 19382 for the sake of randomness.
19382 in binary is:

0100 1011 1011 0110

Now, take every individual portion of 4 bits and turn it into a number:

0100: 4
1011: 11
1011: 11
0110: 6

11 in Hex is B.
So, the number is 4BB6.

So basically, storing it in hex and binary would have the same result but with the latter would require more space presumably.

[Stormrider]

Well, the hex would take more space since you would store it as a varchar, with 8 bits per character, so twice as big as the binary version, but it is more convenient and easier to deal with.

[felgall]

The ideal setup once you decide on a key length is to work out how you can allow the key to be any possible value that fits the length rather than limiting it to just a subset of the values - ideally you want to be able to use characters that are not on the keyboard as well as those that are in order to increase the range of values as high as possible.

An MD5 hash does give you the maximum possible values for the key but is only 16 characters long. SHA1 gives a 20 character key which is a slight improvement. Those are fairly short keys for any serious encryption though. The algorithms don't guarantee that you are going to get that even spread across all the possible values either unless you can somehow get people to use all the possible values in what they enter in to start with and if you can get them to do that then simply truncating keys that are too long would result in more values to test for in trying to break the key than using a hash would. If you are going to use a hash then perhaps a SHA512 with its 64 character key would be a reasonable choice since it at least produces a key length approaching that which you would want to use for this type of application.

[examancer]

Thanks for the tips.