On Tue, Sep 07, 2010 at 02:17:59PM -0700, travis+ml-rbcryptogra...@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. -Jack _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
