[1068] in cryptography@c2.net mail archive
Re: Thoughts on the next target.
daemon@ATHENA.MIT.EDU (Adam Shostack)
Mon Jun 23 23:28:01 1997
From: Adam Shostack <adam@homeport.org>
In-Reply-To: <199706240159.AA187817594@bftzh114.ott.bnr.ca> from Marcus Leech at "Jun 23, 97 09:59:54 pm"
To: mleech@nortel.ca (Marcus Leech)
Date: Mon, 23 Jun 1997 23:05:06 -0400 (EDT)
Cc: dpj@world.std.com, cryptography@c2.net
| Brute-forcing the SecurID hash algorithm, for example would require
| that someone violate their license agreement with Security Dynamics/RSA.
| "Algorithm Thieves today showed that SecurID cards aren't as secure
| as manufacture claims".
If you mean the card hash, its not easy to go backwards
from the output of the card to its seed with a small number of
tokencodes. The output of the hash is substantially truncated. The
card hash has (I think) a 64 bit output, of which you get 4-8 decimal
digits (14-30 bits).
Going backwards from a set of tokencodes would be a cute
trick, seeing as you need to find when the cards clock thinks it is,
which may not closely relate to the real time. (Ace/Server stores
clock drift info on a per card basis, and will actually accept a
tokencode that is up to 10 minutes off in either direction, which
gives you an idea of the accuracy of the card clocks. In fairness to
SDI, the cards may well go unused for a couple of months.)
In conjunction with the time (to the minute), you need to find
the cards seed, which I think is also 64 bits.
Time is calculated as (time(0)+N+1000000)/60
N was a three every time I looked at it, but unlike the
million, was stored as data, not a constant.
So, you need to search some number of time possibilities
(about 2^20 for a year, 2^11 for a day?) on top of 2^64 seeds. On the
bright side, the card hash runs on an 8 bit processor, and would
probably be way efficient on a pentium.
Adam
--
"It is seldom that liberty of any kind is lost all at once."
-Hume
