4 ms·

I wanted the humanhash to depend on the whole of the input, so I use a compression function (similar to a checksum) rather than simply selecting the first `n` b

I wanted the humanhash to depend on the whole of the input, so I use a compression function (similar to a checksum) rather than simply selecting the first `n` bytes of input. The humanhash is not intended to guarantee any level of collision protection, it's simply supposed to be a human-memorable representation of a much longer underlying digest. When computers exchange representations, they should certainly use the full digest. However, even with only four bytes, you're looking at a 1 in 4.3 billion chance of collision. So for user interfaces, where a user merely has to distinguish between different values, or even a situation where two people want to check that they're talking about (probably) the same thing, it remains useful.

waitwhat 15y ago
Your choice of words seems poor. Many of the words sound similar, even words next to each other in the list such as "winner"/"winter", "march"/"mars" and "six"+"ten"/"sixteen". You might want to look at e.g. http://en.wikipedia.org/wiki/PGP_word_list http://en.wikipedia.org/wiki/PGP_word_list to see how others have solved the same problem. It doesn't appear that you've made any attempt to secure this humanhash against a malicious third-party. If the input to humanhash really is the result of a cryptographically-strong hash function, then at first glance it looks like the "XOR everything into an n-byte buffer" is no stronger (and potentially actually weaker) than the naive "just use the first n bytes". (Disclaimer: not my field, although I did take a couple of formal crypto classes once.) If the input to humanhash is arbitrary, and you aren't protecting against a malicious third party, then why not use a much-better understood CRC rather than "XOR everything into an n-byte buffer"? EDIT: On reflection, the input to humanhash has to be short (because the compression function needs to know the length of the input and so can't operate on a stream) and of known length (because you're just xor'ing, and it's trivial to get two inputs to "compress" to the same thing by padding one with NUL bytes.)
- zacharyvoase 15y ago
  You're correct, humanhash was never intended to be secure. I felt that, for usability, I'd have to surrender some collision protection in exchange for brevity. I was originally taking the first N bytes, but I decided to use a simple XOR-based checksum over N chunks of the input instead. This may have been cargo cult cryptography. I hadn't seen the PGP word list; thanks a lot for that. I would integrate that list this very second if I could, but I'm concerned that PGP owns the copyright to the list.
  - Arelius 15y ago
    It's generally accepted, with modern cryptographic hash functions, that's it's better to just take the first N bytes, rather than run a naive checksum over the hash.
mseebach 15y ago
If the input is already expected to be a hash, you don't need to do compression, and if it isn't just MD5 it. I forget what the property is called, but a hash is supposed to change a lot for a small change in the input. Thus, any n bytes from the hash represents the hash equally well. > So for user interfaces, where a user merely has to distinguish between different values, or even a situation where two people want to check that they're talking about (probably) the same thing, it remains useful. Yes, absolutely, as I also wrote. I just wanted (and maybe you do too) to warn that it's not appropriate for sensitive stuff, while the relative complexity of the implementation could suggest that's the case.
- robrenaud 15y ago
  > I forget what the property is called, but a hash is supposed to change a lot for a small change in the input. http://en.wikipedia.org/wiki/Avalanche_effect http://en.wikipedia.org/wiki/Avalanche_effect

waitwhat 15y ago

Your choice of words seems poor. Many of the words sound similar, even words next to each other in the list such as "winner"/"winter", "march"/"mars" and "six"+"ten"/"sixteen". You might want to look at e.g. http://en.wikipedia.org/wiki/PGP_word_list http://en.wikipedia.org/wiki/PGP_word_list to see how others have solved the same problem. It doesn't appear that you've made any attempt to secure this humanhash against a malicious third-party. If the input to humanhash really is the result of a cryptographically-strong hash function, then at first glance it looks like the "XOR everything into an n-byte buffer" is no stronger (and potentially actually weaker) than the naive "just use the first n bytes". (Disclaimer: not my field, although I did take a couple of formal crypto classes once.) If the input to humanhash is arbitrary, and you aren't protecting against a malicious third party, then why not use a much-better understood CRC rather than "XOR everything into an n-byte buffer"? EDIT: On reflection, the input to humanhash has to be short (because the compression function needs to know the length of the input and so can't operate on a stream) and of known length (because you're just xor'ing, and it's trivial to get two inputs to "compress" to the same thing by padding one with NUL bytes.)

zacharyvoase 15y ago
You're correct, humanhash was never intended to be secure. I felt that, for usability, I'd have to surrender some collision protection in exchange for brevity. I was originally taking the first N bytes, but I decided to use a simple XOR-based checksum over N chunks of the input instead. This may have been cargo cult cryptography. I hadn't seen the PGP word list; thanks a lot for that. I would integrate that list this very second if I could, but I'm concerned that PGP owns the copyright to the list.
- Arelius 15y ago
  It's generally accepted, with modern cryptographic hash functions, that's it's better to just take the first N bytes, rather than run a naive checksum over the hash.

mseebach 15y ago

If the input is already expected to be a hash, you don't need to do compression, and if it isn't just MD5 it. I forget what the property is called, but a hash is supposed to change a lot for a small change in the input. Thus, any n bytes from the hash represents the hash equally well. > So for user interfaces, where a user merely has to distinguish between different values, or even a situation where two people want to check that they're talking about (probably) the same thing, it remains useful. Yes, absolutely, as I also wrote. I just wanted (and maybe you do too) to warn that it's not appropriate for sensitive stuff, while the relative complexity of the implementation could suggest that's the case.

robrenaud 15y ago
> I forget what the property is called, but a hash is supposed to change a lot for a small change in the input. http://en.wikipedia.org/wiki/Avalanche_effect http://en.wikipedia.org/wiki/Avalanche_effect