0

I understand that a CRC verifies data integrity by producing a checksum, which is the result of polynomial long division. I've heard hash values referred to as hash checksums, so my question is whether hash functions use some sort of polynomial division as well? I know they break the data up into block ciphers, so my guess would be that the hash functions create some relationship between the polynomial check value and how it's divided into the different blocks. Can someone let me know if I'm way off base here?

Jon Behnken
  • 560
  • 1
  • 3
  • 14
  • This does not seem to be a programming question. You may want to ask on Maths or Cryptography. – Ben Jun 16 '17 at 14:50
  • I'm voting to close this question as off-topic because it's a maths question. – Ben Jun 16 '17 at 14:50
  • I apologize. I actually just downloaded the app and didn't realize where I was posting. Can a moderator please move this topic? Thank you. – Jon Behnken Jun 16 '17 at 14:51
  • This is a legit CS question, OP is just asking the wrong thing (i.e. conflating several concepts) – sircodesalot Jun 17 '17 at 16:53
  • I'm voting to close this question as off-topic because it has been cross-posted on a better suited Stack Exchange site. https://crypto.stackexchange.com/questions/48364/hash-functions-and-polynomial-division – Matt Jun 26 '17 at 18:31

1 Answers1

1

A CRC is a hash function, but there are many other ways to implement a hash function. The other ways generally do not use polynomial division, though there are some that use a CRC as a part of the hash calculation, in order to make use of hardware CRC instructions. Most hash functions use a long, convoluted series of ands, nots, exclusive-ors, integer additions, multiplications, and modulos.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
  • So let me just clarify: a hash function is a one-way compression function, yes? So a CRC could be considered a hash function in that regard? – Jon Behnken Jun 18 '17 at 13:04
  • No. You can only call something "compression" if you have some way to decompress the result. A one-way function then cannot be considered compression. A hash function simply maps a message of arbitrary length into a fixed number of bits. Necessarily then, many possible messages get mapped to the same value. A good hash function gives very different values with only small changes in the message, and spreads the hash values of the messages over all possible hash values. – Mark Adler Jun 18 '17 at 17:11
  • I was under the impression (and have been instructed by academia) that hash functions *are* compression functions. According to [Wikipedia](https://en.m.wikipedia.org/wiki/One-way_compression_function): "**One-way compression functions are for instance used in the Merkle–Damgård construction inside cryptographic hash functions**". Am I conflating concepts here? – Jon Behnken Jun 18 '17 at 17:39
  • They are conflating concepts here. This is a terrible use of the word "compression". However in searching I see that the phrase "compression function" for hash functions appears to be in relatively wide use. So we are stuck with it. In any case, a hash function, even if you call it a compression function, cannot be used for data compression since the data cannot be recovered. This is the "one-way" aspect of the functions, where a great deal of effort is spent assuring that it is not practically possible to recover the original data, _even_ when the hash is the same length as the data. – Mark Adler Jun 18 '17 at 18:12
  • I understand that a hash value can't be reversed (or decompressed) back to the original digest easily, if at all. I suppose there are different semantic views on the term compression. Either way, my question was wondering whether a hash function, in order to perform the "compression", used several iterations of polynomial long division to come up with a value shorter than the original data, which I now see is not the case. – Jon Behnken Jun 18 '17 at 18:31