# Does character encoding change entropy?

This is a question I've been wondering for a while.

Technically these two strings have the same entropy I believe:

fkfnajkfkg%gsddg£5ER£%££££

0110011001101011011001100110111001100001011010100110101101100110011010110110011100100101011001110111001101100100011001000110011111000010101000110011010101000101010100101100001010100011001001011100001010100011110000101010001111000010101000111100001010100011


both 256bits...

My question is, does character encoding affect entropy?

If generated at random, do both the ASCII and binary strings have the same entropy as passwords?

If 256bits is good as an AES key, it's also good as a password right?

I guess a similar question is does hashing a 'weak' password give a lower entropy string than a 'strong' password, consider this:

Blake2B(password) = 7c863950ac93c93692995e4732ce1e1466ad74a775352ffbaaf2a4a4ce9b549d0b414a1f3150452be6c7c72c694a7cb46f76452917298d33e67611f0a42addb8

Blake2B(fkfnajkfkg%gsddg£5ER£%££££) = 03e7415fa598e9062cfd9e3cd269ca618b38b3543501e197b6c095b8749d782234e82779a2e4b489fd9c3b002734763ee3b867835e1a2232a37bf89ef8606d09


Are,

7c863950ac93c93692995e4732ce1e1466ad74a775352ffbaaf2a4a4ce9b549d0b414a1f3150452be6c7c72c694a7cb46f76452917298d33e67611f0a42addb8


and

03e7415fa598e9062cfd9e3cd269ca618b38b3543501e197b6c095b8749d782234e82779a2e4b489fd9c3b002734763ee3b867835e1a2232a37bf89ef8606d09


the same entropy?

If I hadn't told you the first was the hash of password and the second the hash of fkfnajkfkg%gsddg£5ER£%££££, would it change your view?

I also suppose there is a difference between brute forcing a password which is 256bits, and one which is 256 ASCII 1's or 0's, which would be more than 256bit.

Technically these two strings have the same entropy I believe:

We cannot tell how much entropy is in a string by looking at it, as it depends on how it is generated and if the values cannot be predicted by other means. For instance, you just posted these strings on this site, so they would not contain (almost) no entropy when used as keys.

Your strings just represents a bit string, possibly of the same size - as you presume, depending on the actual encoding (I don't know the encoding used for the first string, and I can only assume binary digits for the second string). And those bits may contain entropy.

My question is, does character encoding affect entropy?

No, it doesn't as the character encoding is just about the representation of the bits, not the actual value of the bits. The entropy is present in the value of the bits.

If generated at random, do both the ASCII and binary strings have the same entropy as passwords?

Yes, assuming that the alphabet is not larger than expected.

If 256bits is good as an AES key, it's also good as a password right?

No, because normal humans cannot remember such large strings. You could store them in a password manager though, and then 256 bits of entropy is plenty, if not overkill. Generally we don't need password sizes or keys over 128 bits - as long as quantum computers don't come of age anyway.

I guess a similar question is does hashing a 'weak' password give a lower entropy string than a 'strong' password, consider this:

No, now the value of the bits of the input string contain less entropy, so this isn't comparable at all. The entropy is not expanded by the password hashing algorithm, so the earlier hash contains less entropy than the latter hash.

If I hadn't told you the first was the hash of password and the second the hash of fkfnajkfkg%gsddg£5ER£%££££, would it change your view?

No, because a dictionary attack would almost immediately find the first hash.

I also suppose there is a difference between brute forcing a password which is 256bits, and one which is 256 ASCII 1's or 0's, which would be more than 256bit.

That depends. Let's assume that all the security is in the password or key. In that case we work with Kerckhoffs principle, and we assume that we know how the password is encoded. In that case there is no difference.

Of course, a real world attacker may not work that way. You may use your password for a generic store, and an attacker may not try your particular encoding.

Most humans are terribly bad at remembering 256 ones and zeros. There may be other technical difficulties in entering such a long string of characters as well (screen space, remembering where you are in the string, stealing clipboard contents etc. etc.).

• Note that I'm not so much discussing the theoretical nature of entropy and security in this answer, but I certainly think that my answer cannot conflict with the different notions. It would be an interesting discussion if encoding can influence Kolmogorov complexity, but I don't think it should change my answer. – Maarten Bodewes Oct 3 '19 at 14:00
• thank you for such a detailed and interesting answer. One follow up point... > No, because a dictionary attack would almost immediately find the first hash. - as you said here, it sounds like then, that one could generate a very high entropy looking string, that's actually a hash output or hex representation of a very weak ASCII password and not know it! If indeed the inverse is true, that the hash of a low quality input does indeed contain less entropy due to dict attacks etc. – Woodstock Oct 3 '19 at 14:03
• Yes, but of course the chance of generating such a hash randomly is infinitesimally small. And if you know that it was generated randomly, then there is little point in checking for it happening to collide with a hash value known to have little entropy. – Maarten Bodewes Oct 3 '19 at 14:10

Yes and no. The strings certainly both have the same Kolmogorov complexity.

Some here loosely generalise the cryptographic definition of entropy as Kolomogorov complexity = entropy. That's not quite correct and confusing. Kolmogorov complexity is the thing that cryptographers are interested in when assessing the strength of passwords and seeds. Entropy (information) is measured a-priori of knowing anything other than what you measure at any specific point. Entropy (information) is very much a localised metric and can thus be transformed.

So clearly your two sequences must have differing (information) entropies as they're different lengths due to the encoding. Philosophically and semantically though they're identical. So the effort to brute force either is identical too.

As to then:-

I also suppose there is a difference between brute forcing a password which is 256bits, and one which is 256 ASCII 1's or 0's, which would be more than 256bit.

No, but it might take more RAM/die estate to hold the candidates. The entropy rate of the former is 8 bits/byte, whilst the latter is 1 bit/byte. It may be worthwhile looking at What is the most secure encryption algorithm that keeps the entropy the same or even lowers it?. And also consider the difference between a cryptographic "key" like those above, and a "password" which is like "123456".

• Thanks @Paul, very interesting, one last thing, what about the two Blake2b hashes, one of a weak input, one of a strong input. Are both outputs equal? despite being digests of different strength inputs? – Woodstock Oct 3 '19 at 13:54
• ‘Kolmogorov complexity is the thing that cryptographers are interested in when assessing the strength of passwords and seeds.’ [citation needed] – Squeamish Ossifrage Oct 3 '19 at 17:13
• The proposition ‘your two sequences must have differing (information) entropies’ doesn't make sense, because entropy is a property of a state of incomplete knowledge or of a process whose outcome is unpredictable, such as a password generation procedure or what an adversary knows about your password after you use that procedure to pick a password; the entropy of a particular password is a nonsensical idea. – Squeamish Ossifrage Oct 3 '19 at 20:19
• I won’t labour the point any further other than to encourage you to think of the consequences of your statements. If passwords have no entropy, you’re disavowing all information, all books and all my favourite Abba songs. And all the Wikipedia pages about the differences between Kolmogorov complexity and entropy. But they all exist, don’t they? – Paul Uszak Oct 6 '19 at 3:43
• Unless you’re pulling my chain, I expect that it’s just an unfortunate and problematic semantic difference. Like calling AES a permutation which it clearly isn’t in anyone’s common understanding of ‘permutation’. – Paul Uszak Oct 6 '19 at 3:43