[cryptography] anyone know how OTP tokens work?

Jack Lloyd lloyd at randombit.net
Tue Sep 7 17:36:18 EDT 2010

On Tue, Sep 07, 2010 at 02:17:59PM -0700, travis+ml-rbcryptography at subspacefield.org wrote:
> I'm curious how OTP tokens work.
> They only emit a few digits, and they can be resynced with the server
> by entering two values, so if I'm thinking correctly, two values must
> capture the entire state of the device (the seed for a PRNG or
> whatever they use).  I assume that there's something in place to
> prevent an adversary from deriving the seed from two consecutive
> output values, so I'm curious how that works.

I don't know much about these tokens (I'm assuming you're referring to
RSA SecurID tokens?), but it doesn't seem necessarily required that
the entire internal state be captured in a pair of outputs (and really
that property seems like it would be highly undesirable). I believe
the two sequential values for resync is used only so that when the
token's internal clock drifts, the server can figure out where the
tokens clock is at and save that time offset against its local clock
so for future transactions it has a starting guess. Normally (ie when
the token is used regularly) the server can figure this out for
itself, simply by taking its current clock plus its last guess as to
to token's clock offset and searching to see if there is a matching
output in the nearby time space.

I don't know offhand exactly what the algorithm used in SecurID is (is
it still a trade secret?), but conceptually you could think about it as

 MAC(secret, timestamp) % 100000

with a site specific secret. The secret can (and hopefully is) much
larger than the token's output for any particular timeslice.


More information about the cryptography mailing list