I'm working on a API which is serving content based on user requests. What I'd like to achieve is as follows: Having a constant key stored both on the server and the client machine (as a means of identifying a specific user) I'd like to be able to generate a hash with a one-way cryptographic algorithm on the client side so that the generated hash is different each time but I would still be able to identify the user tied to that hash on the server-side (through the constant key stored on the servers database) using 'some function'. The generated hash on the client-side would be used to make a HTTP request to the servers REST API which would verify if that hash is tied to any of the keys from the database and if so, serve the content to its users.

ex: https://someserver.com/content?hash_here - would send content back to the browser only if the hash (hash_here) matches with one of the users hash in the database (after the cryptographic 'magic' I'm talking about is done)

My goal is to omit authentication, as the client would be a raspberry pi device and authentication should work without setting up any credentials other than the hash key stored both on the client and server side.

My question, as somebody having close to no knowledge on the subject: Is there any cryptographic algorithm that does that, and if so, which one?

  • Why reinvent the wheel? Things that springs to mind is client certificates or a JWT token.
    – vidarlo
    Jul 9, 2021 at 19:03

1 Answer 1


What you describe is implemented in algorithms like HOTP or TOTP.

The basic idea here is to have a common secret between client and server and some kind of implicit "counter" shared between client and server. This counter can be a real sequential counter in case of HOTP or a representation of the current time in case of TOTP. Then combine secret and counter with some hashing - specifically a HMAC truncated to the desired length.

The result is a function which depends on a shared secret, returns a new value whenever it is called (as long it is not too rapidly called in case of TOTP) but still makes it possible to verify the result by the (synchronized) server.

You must log in to answer this question.

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