It never makes sense to express cryptographic hashes in hexadecimal. If the values are meant to be read by humans, then decimal or base 26 would make sense, or maybe things like Bubble Babble. If for computers (e.g., a shell pipeline or cut and paste), then base 94 (printable ASCII not including space), base 256, or the set of non-weird Unicode characters would be more compact (omit whitespace, control and formatting, characters that cause bidirectional text, characters that join with adjacent characters).
Other possibilities:
Decimal
26
32 (like base 58 below)
36 (26 plus digits)
52
58
62 (26*2 plus digits)
94
256
Unicode
Hexadecimal is simply lazy programming. Radix conversion is computationally cheap.
There remains the minor issue of how to specify the width and how to pad.
1 comment :
True in theory, but using hexadecimal does make practical sense now, from the viewpoint of backwards compatibility for working with all the existing software which accepts hashes in hexadecimal... :)
And the padding issue is not trivial; probably there would be more bugs and more time wasted in coding and debugging if some more theoretically efficient ASCII scheme were used.
Post a Comment