[Evans] There's an interesting story about using hash chains for hotel doors.
I'm not positive if this story is true, but I've heard it from fairly reputable sources
and it seems too good not to be true.
So if you think about a hotel, you've got rooms--
let's say this is Room 387--and you've got a check-in desk
that may not be connected by any wire to the room.
What you'd like to happen is when a new visitor checks in--
let's say it's Alice--the desk at the check-in can give her a new key,
and that key will allow her to open the door.
There's no connection between the check-in desk and the door,
and we want to know that Alice will be able to enter the room.
Whoever stayed in the room previously--let's say that was Bob--
shouldn't be able to enter the room anymore.
At the point after Alice checks in and enters the room,
Bob should no longer be able to enter it.
We'd like to have all this happen without needing any coordination
between the desk and the door.
One way to do that would be to use a hash chain.
What the door will do is when it reads a card--
and I'll write this in sort of Python-ish code--
the door will have some stored value x.
What the door will do is check if the value of hashing that key is equal to x, the stored value.
If it is, the door will unlock and everything is good.
We open the door with the correct key.
There's another situation that we need to test for,
and that's if the hash of the hash of the key is equal to x.
If the hash of the hash of the key--if we're thinking about a hash chain,
that would be the next key in the hash chain.
If that's the case, we also want to unlock the door,
but we want to update the value that's stored as x.
We'll update that value to be the hash of the current key, hash of k.
So that's our read protocol.
What this means is that if Bob is using the room first,
his key is k1, and his key will have the value some number of hashes on some secret,
and the value of x would be m + 1 of those hashes.
And Bob keeps opening the door, going through this path through the code.
There wouldn't really be a Python interpreter in the door.
This could be done by something much simpler than having a full Python interpreter.
Then when it comes time for Alice to open the door,
Alice's key would have the value 1 fewer hash of s.
That means that the value of the hash of the hash of Alice's key is equal to this value,
hashing m + 1 times starting from s, and that means Alice would open the door.
It would change the value of x, so now it no longer works for Bob.
But the next person who enters, it will work, and then it will stop working for Alice.
So what the check-in desk needs to do, it needs to keep track of some secret,
and it needs to keep track of the number of the guest.
The initial value stored as x needs to be set,
but once those are done, there's no coordination needed.
Every time a new guest arrives, they'll be given a key,
which is the result of hashing n times starting from s,
and the value of n would be decreased by 1.
So this is our design for allowing secure doors with a sequence of users.
So to see that you understand it and understand hash chains well, we have a quiz.
What would cause problems with this design?
If a criminal could extract the stored value from the lock;
if a guest checks in to the hotel but never actually enters her room;
or if a guest enters the room many times.
