0
$\begingroup$

I‘ve argued for quite some time with a friend about wether or not this C# method can be qualified as a Hash Function.

public override int GetHashCode() {
    return X.GetHashCode() * 31 + Y.GetHashCode();
}

My argument is that this simply returns a 32-bit integer value, using a fixed input size of 2 variable 32-bit integer values (and one constant 32-bit integer value), while one of the prerequisites for a Hash Function is an arbitrary input size. Using two 32-bit integer inputs is not arbitrary as far as i can tell. Unless arbitrary refers to the possibility in general (meaning 2 different functions can have fixed-size input, but the specific sizes aren‘t limited and can be different for each) and not the need for each function to have the ability to accept an arbitrary input size, while returning the output with the same size, no matter the input size.

The values of X.GetHashCode() and Y.GetHashCode() are variable 32-bit integer values and are the result of a Hash Function.

Now, the way i see it, you can just simplify that code to: h(x, y)=x*31+y , where x and y are 32-bit integer values. Which leaves you with 64-bit fixed input size, so either my simplification is faulted, or it‘s not a Hash Function, correct?

If that simplification is not correct, why not?

And what exactly dis/qualifies this as a Hash Function?

Does the input values being the results of a Hash Function affect the qualification of the code as a Hash Function in any way? Even if it is guaranteed that the inputs will be the result of a Hash Function, that doesn‘t make this function a Hash Function, does it? (Like how 'f(log2(4), log2(3)) , where f(x, y) = x+y' would not be a logarithmic function just because of the inputs.)

Thank you for your time. Any suggestion is much appreciated. Also, sorry if some parts are unclear or poorly formatted. I‘m not really versed in this, be it the mathemathical definitions, the language, or stackexchange in general.

Improve this question
$\endgroup$
2
$\begingroup$

The C#/.NET GetHashCode() is not a cryptographic hash function. As a non-cryptographic hash function I think what you've written is reasonable assuming that X and Y are the only "public" properties that make up the object.

Having said that, cryptographic hash functions are very different both in implementation and purpose than C#/.NET/Java hash codes and probably other languages as well, so you might want to take this question to a more appropriate venue.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Thank you for your answer. Also, I posted the question in cryptography, because i was looking for an answer related to Hash Functions themselves, not the programming implementation. I only added it to give more information about the origin of the question and because it could‘ve been relevant. (This probably would fit better in another topic) How would the addition of new properties (without changing the current implementation of the method itself) affect the qualification of this method as a Hash Function? Also, X and Y are of a different class than the one implementing the method. Thanks. $\endgroup$ – Lexyth Feb 17 at 3:32
  • $\begingroup$ There are several related concepts called "hash functions". In general, they take some single input and produce some output. Cryptographic Hash Functions take a variable sized input (from 0 up to some security bound) and produce a fixed-size output, with guarantees about collision resistance, preimage resistance, and second preimage resistance. eXtensible Output Functions take a variable length input and produce a variable length output, with similar guarantees. General Hash Functions don't have any guarantees, but usually take either a fixed or arbitrary input and produce a fixed-size output. $\endgroup$ – SAI Peregrinus Feb 17 at 18:15
  • $\begingroup$ @SAIPeregrinus Thank you for your answer. So i take it that the definition of Hash Functions taking an arbitrary amount of input refers to the possibility of different functions being able to take differing fixed-size input and not the need for every function to be able to process arbitrary-sized input? $\endgroup$ – Lexyth Feb 18 at 20:52
  • $\begingroup$ Hash Functions ≠ Cryptographic Hash Functions ≠ Password Hashing Functions ≠ Password-Based Key Derivation Functions ≠ Key Derivation Functions ≠ Message Authentication Codes ≠ eXtensible Output Functions. All those things are different, all are related. Cryptographic Hash Functions MUST take variably sized inputs. But hash functions in general don't necessarily need to. EG there are integer hashing functions that hash 32-bit integer values. They're not cryptographic hash functions, but they are hash functions. $\endgroup$ – SAI Peregrinus Feb 18 at 21:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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