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 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.)
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.
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.
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.)