Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What do you think of converting SpookyHash into semi-secure 192bit hash function by this way:

  • increase security by using 8 * 8byte = 512bit blocks instead of 8 * 12byte blocks, but remaining 8 * 12byte = 768bit state (so that 256bit are used for "oracle")
  • run more EndPartial rounds in End, to produce more entropy
  • take h0, h1, h2 as a result to produce 192bit hash.
  • and it looks like Short hash should be removed :( or rewritten to use more state

How secure will this function be? How many EndPartial rounds would need to be run?


By saying "Semi-Secure" I mean:

  • CityHash used by Google for distinguishing keys one from other, but Jean-Philippe Aumasson shows it is very easy to produce collisions for (as well as for MurmurHash3)
  • There is need for hash which should be fast for using as signature
  • but probability of occasional collisions should be marginal
  • and attack on should be unprofitable: if one should spend a 1 GPU*year (ie 1 month for average funded company) time to perform preimage attack or recover "secret" from HASH("secret"+"public"), then function is secure enough (but certainly it is not cryptographic)

ie "Semi-Secure" means attack is possible, but is unprofitable for opponent for current usage of function. And occasional collisions are rare enough.

Example: one of rejected SHA-3 competitors "Aurora-512" were rejected cause it were shown that 2^234 attack is possible... "Semi-secure" - is about 2^58 (probably) resistance function.

share|improve this question

closed as primarily opinion-based by e-sushi, AFS, hunter, rath, archie Apr 9 '14 at 1:12

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Just use a proper hash instead. You don't know what you're doing, and even hashes designed by experts need a lot of review before you should use them. – CodesInChaos Apr 7 '14 at 19:31
Could you define what you mean by “semi-secure”? I’m asking because it’s a long way from a “semi-secure” hash to a “cryptographically secure” hash, and I don’t think SpookyHash is a good base to try bridging that gap with some self-tuned fiddling. Instead, use a well-vetted crypto-secure hash like CodesInChaos said. (Obvious recommendations would be SHA2, or maybe even SHA3). – e-sushi Apr 7 '14 at 20:29
"How secure will this function be?" Semi. – hunter Apr 7 '14 at 20:30
@hunter [+1] Funny… unless you meant “semi” as in ”if it's semi-broken, it's broken”. In that case, please excuse my cynical smile. ;) – e-sushi Apr 7 '14 at 20:35
average funded = some kid at a computer with a botnet of a few thousand computers that he can send commands to, well funded = a petaflop supercomputer in the basement. – Richie Frame Apr 8 '14 at 9:43

SpookyHash is clearly designated by its authors to be a non-cryptographic hash. In the cryptographic world there is simply no room for semi-broken at this level. Either there is some kind of margin to reach, say 128 bit security level or there isn't. This means that it should stand up to the current known attacks and that the design conveys enough piece of mind for the crypto analysts to call it (anywhere near) secure.

Bit fiddling or only adding rounds is likely not going to help. Even people that have experience in the field find it hard to create a secure hash. Take a look at the number of entries withdrawn or removed from the second round of the SHA-3 competition to get an idea what it constitutes to create a hash with even a minimal security level.

share|improve this answer

Issues with the question first:

  1. Security is not something you can duct tape on to anything you want after the fact.
  2. You can never increase information entropy by processing data. It can be kept constant or decreased depending on whether you are doing a lossless or lossy tranformation.
  3. HASH("secret"+"public") is not necessarily secure for all crypto-hash functions as a MAC. Use HMAC or a MAC mode if its explicitly defined in the algorithm's paper.
  4. Are you sure your estimates are right? Do you have any way of knowing?

Answer: Security is not something that can or should be added on after the fact for any algorithm. There are many good cryptographic hash functions to choose from. You don't need a new one. These algorithms outclass insecure functions in all respects except* speed. If you tried to make one "secure", then it would be a different algorithm and would likely be slower and otherwise inferior to serious crypto-hash functions.

There are good algorithms like Sha2, Skein, Blake, Blake-2, and siphash**. Sha2 is part of the SHA family. Skein and Blake were Sha-3 candidates. Blake-2 is a faster variant of Blake with a smaller security margin. Siphash is a fast PRF.

Siphash uses a 128 bit key, has a 256 bit state, and has a 64 bit output. Its speed is competitive with general purpose hash algorithms. It is designed by Jean-Philippe Aumasson and Daniel J. Bernstein and can be used in hash table algorithms to prevent hash collision based DOS attacks -- if the key is kept secret. The downside is that is not big enough to use as crypto-hash, there have not been publications analyzing it or reduced round mode, and a 64 bit output might be too small. 64 bits of output provides up to 32 bits of collisions resistance, so someone with the key could generate collisions by brute force.

*Generalization disclaimer: This is a generalization. Other algorithms may take fewer bytes of machine code or less space in hardware implementations, but these are usually not concerns. (CRC, for example, is small but also not crypto secure.)

** A MAC algorithm, a PRF, or a general purpose hash function with properties that help resist hash collision based DOS attacks. It is not secure as a drop in replacement for cryptographic hashes like Sha2, etc.

Edit: SHA-1 is still usable, but why risk it for anything other than legacy support? Keccak was chosen for SHA-3 but is in a weird state right now.

share|improve this answer

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