-5

Is it possible to programmatically generate different hash functions? Of course, it is. We can simply tweak the numerical parameters of the hash function. But is there a known way to generate secure hash functions programmatically? I got an idea for a new authentication system, but it relies on using a hash function that MUST be unknown to the attacker. I want the attacker to not be able to try every KNOWN hash function on the planet Earth and break the security.

The idea is the following. I want to be sure someone that someone is who they claim to be. All I know is their initial “name” and a hash function. The name can be any string of fixed length. They hash the name with the hash function and send it to me. I can verify they are who they claim to be. How? I hash the initial name and check whether the result is the same as their hash. The next time we connect the same procedure is repeated only this time we use the new hash as the source. Obviously, there is a problem if we use a common hash function such as SHA 256 as the attacker can easily try different functions on the name until he gets the same hash. That's why I need to be able to generate a unique hash function that the attacker cannot easily guess.

Improve this question
8
  • Welcome! Your post would be greatly improved with examples and expanding on what it means to programmatically generate hash functions. Also, what goal are you trying to achieve?
    – user2320464
    Mar 20, 2021 at 20:21
  • 9
    "I got an idea for a new authentication system but it relies on using a hash function that MUST be unknown to the attacker." - using an unknown (and thus not established) algorithm is a bad idea from start. Designing your own authentication system likely too. But you can simply use an existing secure hash function and prefix the data with some salt unknown to the attacker, which should be sufficient to add the "unknown" you need.
    – Steffen Ullrich
    Mar 20, 2021 at 20:24
  • It's just an Idea at this point. I have added details in my questions. Please ask If you need any more details.
    – Teodor Dyakov
    Mar 20, 2021 at 20:48
  • Now that i think about i might have just reinvented blockchain in a slightly different context.
    – Teodor Dyakov
    Mar 20, 2021 at 20:52
  • 1
    One general rule of cryptography is: Everything needs to be secure even when a wealthy, motivated, intelligent, and highly experienced entity knows every detail of the entire system, except for the key. Remember also that it's easy to come up with a system that you can't break yourself. There's no shame in that, as long as you don't expect others to be unable to break it as well.
    – Ghedipunk
    Mar 22, 2021 at 5:55

2 Answers 2

Reset to default
0

Your system is not secure at all.

Let's suppose you have several usernames that must be allowed, e.g.

  • Teodor Dyakov
  • Steffen Ullrich
  • Ángel

Now, when someone calls at your server and says hey, "I'm Steffen Ullrich" you want to ensure he is the Steffen Ullrich you want (the one employed by your company, the one who paid for your services...), and not someone else impersonating him or, simply, sharing the same name.

Now, someone connects to your server and says "hey, I'm <user>". Given your approach, they need to provide that using a custom hash function, which you would have to provide to them somehow. At that point, Ángel could choose to apply that hash to the name 'Teodor Dyakov' instead. So, your solution doesn't work.

What you could do is to securely provide the user the output of your hash for their name. So you would tell Steffen that their hash is cacb810d9776a48e4d93be0273f5e5ac9a7338cb, but I would only know my hash to be b2351ea565858a359e56c2624d38f38d30a828ae and (given the unknown hash function) would be unable to guess Steffen's hash. From the user's point of view, this would be a password provided by the server.

The server could implement this as a hash. You can produce your "new hash" by using a HMAC with a secret key known only by your server, and this way to avoid storing a password¹ for each user. But doing this means that a given name can only have one password. If one password is compromised/stolen, it's impossible to change it to a different one (unless you changed the password for all your users at once…). So just use a regular password system instead (with server-generated passwords, if you wish).

¹ Which you must not be storing as-is, all recommendations of hashing passwords apply.

Improve this answer
0

The problem here is that you are trying to use the hash function as the ultimate secret. But it can't be a secret. In your scenario, you know the hash function. That means that anyone with access to the server knows it, too. Your scheme falls apart upon first use.

That's why encryption uses keys. The process can be known (as it must be) but the key remains secret.

It sounds like you are trying to create a "digital signature", but we already have very mature and well-tested methods for that.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .