16
$\begingroup$

I was wondering why most "normal/unsafe" crypto hashes like SHA-256, SHA-512, Whirlpool, RipeMD-160, MD5, etc. are HEX encoded.

But most "secure" crypto hashes (KDF' ) like bcrypt and scrypt are Base64 encoded. Why?

somewhere I heared that Base64 shortend the string for like 20%. Isn't that extremely bad for password hashed during iterations and makes them less collision resistent?

And if Base64 is really for some reason more secure, then why does Argon2 output HEX encoding?

Improve this question
$\endgroup$
5
  • 6
    $\begingroup$ 'Isn't that extreamly bad for password hashed during iterations and makes them less collision resistent'; actually, these hashes never do hex/base64 encoding of internal hashes; instead, internal hashes stay represented as bitstrings; the hex/base64 encoding is done only on the final output (and is there mostly because external entities can't handle arbitrary bitstrings that well) $\endgroup$
    – poncho
    Commented Jul 28, 2017 at 15:17
  • $\begingroup$ but when you iterate the hash you take the output hash ( so a b64 or HEX ) value and input it like a normal string into the hashing algo . And reverse the process . Have I misunderstood something ? $\endgroup$
    – Richard R. Matthews
    Commented Jul 28, 2017 at 15:29
  • 9
    $\begingroup$ 'you take the output hash ( so a b64 or HEX ) value'; no, the output of the hash may be a 32 byte string, where each byte is a value between 0 and 255. When we display the hash, then we convert it into something a bit more friendly (b64 or hex), but we don't bother if we're just resubmitting it to the hash function... $\endgroup$
    – poncho
    Commented Jul 28, 2017 at 15:32
  • 1
    $\begingroup$ @RichardR.Matthews Just for example, English speakers call their mother "mother", Chinese speakers call their mother "妈妈". "妈妈"(2 characters) is much shorter than "mother"(6 characters), but the meaning of the word "妈妈" isn't unclear than "mother", because these two words are the representation of the same concept. $\endgroup$
    – DDoSolitary
    Commented Jul 28, 2017 at 15:41
  • 2
    $\begingroup$ you are more likely to see a b64 encoded password hash in a database because the databases are unlikely to accept non ASCII data, and b64 is the most common option that takes the least space $\endgroup$
    – Richie Frame
    Commented Jul 29, 2017 at 1:13

4 Answers 4

Reset to default
33
$\begingroup$

The algorithms themselves just output binary (i.e. bytes) if you read their specifications. It's the implementation in API's and applications that output the hexadecimals and/or base64.

Sometimes there are also ad hoc standards / common practice that specifies a certain output format. This is for instance the case for the output of the bcrypt password hashing algorithm. In that case it's not just the hash that is displayed but also the type of algorithm, number of iterations and if course salt.

Base64 is more efficient than hex, while hex allows developers to easily see the value of the encoded bytes. The value of the bytes as well as the amount of bytes are just easier to see in hex; the amount of stored bytes is for instance simply half of the displayed hex digits. However for textual formats or indeed larger hash values base64 may be chosen for its efficiency (~33% overhead for base64 vs 100% for hex, assuming each character occupies one byte).

The command line utilities md5sum, sha1sum and their successors have always kept to outputting hex; it's to be expected that hex is therefore more likely to be output by applications that want to remain compatible.

Note that I've changed the case of the terms "Base64" and "HEX" in this answer to lowercase to be compatible with RFC 4648: The Base16, Base32, and Base64 Data Encodings which tries to standardize the encodings. It only uses the uppercase variant in the title. "Hex" is an abbreviation, not an acronym, so all uppercase does not make sense.

Personally I prefer all uppercase for hexadecimals; people recognize the upper part of letters / digits more easily, so it makes sense to use it as default (and on all my old computers the characters were also in uppercase, so they are in most debuggers).

Note that many (online) tools do not clearly specify the input / output format. In that case it makes sense to look for better tools rather than trying to find out what kind of format the tool accepts.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Certain kinds of hashes are as likely to be validated by human eyeballs as by machines, while others are intended to be compared solely by machines. If a hash will be processed solely by machines, base64 or base85 would likely be a more efficient choice than hex, but some humans may be more able to look at two hex strings and say whether they "seem" identical than would be possible with base64 [if someone replaced a file with a malicious one chosen so that the first 10%, last 10%, and middle 10% of the hex hash matched even though the rest were random garbage, some people might not notice... $\endgroup$
    – supercat
    Commented Jul 28, 2017 at 23:11
  • $\begingroup$ ...but if people who receive a file randomly pick part of the hex signature to validate, phony files would likely get caught at by at least some users, who could then sound the alarm for everyone else.] $\endgroup$
    – supercat
    Commented Jul 28, 2017 at 23:12
  • 1
    $\begingroup$ Also worth noting, that if you are putting encoded values into urls, HEX is url-safe, whereas base64 is not - because it uses / and + characters. You can get url-safe versions of base64 which substitute / with _ and + with -. $\endgroup$
    – guysherman
    Commented Jul 29, 2017 at 17:40
  • $\begingroup$ It's also easier for programmers to debug crypto code when the "correct" answers are in hex, which corresponds directly to the byte array in question. $\endgroup$
    – chrylis -cautiouslyoptimistic-
    Commented Jul 30, 2017 at 0:47
29
$\begingroup$

Using Base64/HEX has nothing to do with security of a hash algorithm.

Base64 and HEX are ways to represent binary data, which is the actual output of a hash algorithm.

Base64 is shorter simple because it uses a larger charset than HEX. (64 characters vs 16 characters)

Besides, algorithms like SHA-256 and SHA-512 are only "unsafe" when used for password hashing(or similar scenarios). In fact, bcrypt/scrypt/PBKDF2 are simply based on these normal algorithms, but make use of some techniques (salt, many iterations with MAC, …), to construct a algorithm that is secure for password hashing.

Improve this answer
$\endgroup$
1
  • 4
    $\begingroup$ As this answer says, B64 or hex are purely display conventions for the same underlying bit patterns. $\endgroup$
    – JesseM
    Commented Jul 28, 2017 at 23:14
0
$\begingroup$

Base64 and Hex are just two different representations of the same value. Base64 uses more characters and therefore the representation is shorter.

However, the Hex representation is unambiguous except for upper or lower case letters. This is not true for Base64. Bcrypt, for example, uses its own Base64 encoding, which increases the implementation effort considerably and is an additional source of errors.

If no representation is specified by the algorithm, the hex representation is longer but also less error-prone.

Improve this answer
$\endgroup$
0
$\begingroup$

When you look at saving the hash to a SQL server DB, I would also suggest that you use Hex, rather than Base64.

With SQL Sever the default configuration will ignore case (case insensitive), and because Base64 uses letters of different case as part of its encoding (byte value of 'a' is not equal to 'A'), if you would use your hash to find or match a hash in the DB (using the WHERE hash = 'inputValue'), it would mistakenly match a value where the case is different.

Like the original question and answers agree on Base64 requires less storage space as a VARCHAR, but if you have to decide between hash collision safety vs. storage, the former may be preferred for security or accuracy.

Note: If you extract the hash value from your DB using the username and match the password hash in code you also mitigate the case insensitive problem. So in this case Base64 would make sense as the potential problem is mitigated.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.