Hallo Frank, thanks for your suggestions. I'm glad that *finally* somebody is asking whether we chose the best parameters.
It would certainly help to shrink the tables to a more manageable size.
However, the trade-offs work out such that shrinking the tables causes a
much smaller success probability, significantly increases the cracking time,
or a combination of these two.
In your example, bringing down the storage requirements by a factor of 200
(to 20 GB) while keeping the success probability at 50%, the attack time
increases by a factor of 64,000. That moves us from minutes to years.
Attached is our calculation; you can change all the parameters. Change cell
D14 to 2^30 for the 20GB scenario.
Your second suggestion, closer monitoring the contributors, runs somewhat
contrary to the anonymity we promised. Having, said that, we appreciate
getting data for statistics. If you are willing to share statistics with us
and haven't opted in by activation the '--network' option yet, then please
do so now.
Thanks again to all the contributors. And thanks to Frank for starting this
discussion.
Cheers,
-Karsten
On Mon, Oct 26, 2009 at 1:25 PM, Frank A. Stevenson <[email protected]>wrote:
> Some thoughts as a follow-up to the latest news on the project status.
>
> I think it is a safe assumption that everyone here is interested seeing
> a A5 break. And hope that small setbacks won't discourage participants.
>
> But I think this would be a good time to take a break and discuss the
> approach that is being taken, as I think there are still some serious
> issues that needs to be addressed. What I have in mind is the size of
> the tables, and the unreasonable requirements that these place on the
> participants of the project. The way things are now, participants need
> to make the tables available online for a long long time after they have
> been computed. This is not something I am interested in. I can write
> code, use my GFX card to heat the house in winter, but I want to move on
> to other projects when I am 'done' ... this project doesn't really have
> an end in sight.
>
> An alternative way of accomplishing the project goals could be
> (suggestion only):
>
> Change the distinguishing points to 32 bits - and reduce chain length to
> 1 (don't do rainbow tables). My high end ATI card could complete one of
> these mega single link chains every 30 seconds.
>
> With this approach, the completed table would be less than 20 Gb - and
> it would be feasible to distribute it as a torrent. Making the table
> easily available long after it has been completed.
>
> Admittedly it would take much longer to recover (crack) a key with this
> table. Maybe around 1 hour on a single CPU thread, but this needs to be
> done quicker, it could also be parallelized, for multiple conversations
> using the GPU. Also the entire process can be done off line.
>
> Also remember that this approach is probabilistic, and keys can be found
> with only a fraction of the table completed. Depending on how much known
> plaintext there is in the GSM transmission, fewer chains need to be
> caclulated. If for instance the stated goal with the project would be to
> have 5% coverage - and the finished table should be around the size of a
> HD movie torrent (10-20 Gb) - 28 bits distinguishing points would
> suffice, with the added benefit of speeding up the actual cracking to a
> few minutes of computation. For instance an ATI Radeon HD 5850 card
> could do compute the entire table in ~165 years of computing.
>
> Also to increase the number of participants, we need to identify who
> they are, and package the software in a way that makes it easy for them.
> For example if we want gamers to help, the software should be a simple
> Windows application that installs and runs with a few mouse clicks.
> Stats on who has computed the most chains is essential to boost their
> egos, etc...
>
> - my opinions, and advice. Remember free advice is worth exactly what
> you paid for it :-)
>
> cheers,
>
> Frank A. Stevenson
>
> _______________________________________________
> A51 mailing list
> [email protected]
> http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
>
090929.Rainbow.Tables.XLS
Description: MS-Excel spreadsheet
_______________________________________________ A51 mailing list [email protected] http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
