I have an offline safe at a remote location that I want to give people access to at my discretion. I would like to control who and when they have access, without having to travel to the safe.


  • I would like "Peter" to be able to open the safe, which is at a remote location, tomorrow.
  • In my office, I sign the text "January 30, 2021" with my private key and give it to Peter.
  • Peter travels to the safe and enters the signed text into the safe.
  • The safe verifies the signature with a corresponding public key.
  • The safe checks the current date and opens itself.

Problem: The signed text is very long. The safe would have a keypad and a small screen, but entering more than 10 or 20 characters would be difficult.

To solve it, I'm thinking about e-banking solutions. They started with cross-off-lists. Such a list could be used where each number on the list could be assigned to a date. Now, I'd like to avoid shared secrets and cross-off lists.

Banks moved to mechanisms like photoTan where they display a QR code to the user; the user scans it with their smartphone, then get a short sequence which they enter back into the banking website.

Such a thing would work. I would like to perform such a "proof" where the safe can send a long challenge to the user, but the user can only respond with a short challenge-response. What are those algorithms?


You could use OTP for this.

Create a random secret and add it on the safe and your phone. When you want Peter to access the safe, you use your phone to pick a future date and generate the token, and send it to Peter. That token could be valid for an hour, or six, or a day, so adjust your generation algorithm accordingly.

That would create an issue when you want two or more people to access the safe at the same time. This could be adjusted by having 10 OTP secrets on the safe (0 to 9), and you concatenate the index of the selected key to the password.

Let's say the OTP for "January 30, 2021" on the secret 2 is 83641398, so Peter would have to enter 283641398 on the safe, and Jane would have secret 1, and her token would be something like 1977433. The safe would get the first digit to identify the secret, calculate the token, and authenticate the user. 9 digits is long enough to deter bruteforce, and short enough to be entered on seconds.

As an OTP is time-dependent, you have to keep a clock on the safe. It does not need to be accurate to the second, because the token life would be at least a couple hours, so even a 15 minute drift would not bring much difficulties to Peter or Jane.

And being time-dependent, the password don't have to be revoked later, and it would be useless on the next day.

  • I would like to avoid shared secrets, since, with secrets, I could work with sufficiently long cross-off lists. OTP uses a shared secret. There's U2F which doesn't, but also doesn't work with short challenge-responses but requires some sort of yubikey or NFC interface. Ideally, I would have an arbitrary number of users. I don't mind if they have to enter their user names before the whole authentication sequence starts, this is also the case with e-banking solutions. But I don't want the safe to have a user list. – Lemon Sky Jan 29 at 20:54
  • The secret is only shared between you and the safe. And it does not matter how much users you have, as long as the concurrent users are less than 10, or less than 100 (so you have to put 100 secrets on the safe). – ThoriumBR Jan 29 at 21:09
  • Thanks but according to the original question, i am looking for a solution without shared secrets. – Lemon Sky Jan 31 at 6:47
  • 1
    There's no way. You cannot authenticate something unless both parties know part of the secret. On TLS, one side have the public key and the other have the private key. On common password authentication, one side have the password and the another have the hash. On the daily mechanical lock, the lock have the secret and the physical key have the indentations. There's no authentication without sharing some form of secret between the parties. – ThoriumBR Jan 31 at 12:50
  • 1
    You do have a shared secret, it's the CA Certificates. There's a list of them on your browser and OS. StackExchange says that LetsEncrypt certified them, and your browser checks its side of the secret to see if the site is telling the truth. – ThoriumBR Feb 1 at 12:19

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.