Thereafter, this secret key is used by both sender and receiver to encrypt the current time and produce a hash code.
Also noteworthy: the current time is divided into coarse time periods (typically UNIX time divided by 30s?), meaning that slight differences in clock time of all participants don't matter because they can reproduce the same hash code during the time period.
Yes, all part of details left out of my general overview.
Time increment rollover is an issue even if clocks are synced perfectly. This is due to an uncontrollable human factor --- delay from the time the code is generated until it is input and submitted.
To account for this, most receivers will check the provided hash code against both the current and the previous time increment.
Comments
Also noteworthy: the current time is divided into coarse time periods (typically UNIX time divided by 30s?), meaning that slight differences in clock time of all participants don't matter because they can reproduce the same hash code during the time period.
Yes, all part of details left out of my general overview.
Time increment rollover is an issue even if clocks are synced perfectly. This is due to an uncontrollable human factor --- delay from the time the code is generated until it is input and submitted.
To account for this, most receivers will check the provided hash code against both the current and the previous time increment.
Very cool! This makes a lot of sense across the board. Thanks for explaining this!