On 05/17/2010 11:13 AM, sascha wrote: > On Mon, May 17, 2010 at 02:01:34AM -0700, MIHAITA ADELA wrote: > >> Hello, >> >> I'm not sure I understood the whole process of the A5/1 attack and I have >> two more questions: >> >> 1) the tables and the lookup provides an A5/1 state that generates those 64 >> bits of keystream.; which state is this? is it the state after the 100 steps >> with majority clocking and that's why you need to backclock the state >> provided by the tables? >> > > (NB: please note that the table format has recently been changed in this respect. Not all information you might find necessarily reflects this)
> The immediate result from the table lookup process gives you the > state before 100 clockings. With a little forward-then-backward clocking > on this result you can find a few more valid states (i think it was 3%). > This is not entirely correct. With 100 clockings forward, and 100 backward (all done with majority clocking), you get to some 13.0 states on average, which all (by definition) produce the same keystream. Clocking further forward and backward than 100 is possible, but then the keystream may be different. If you verify that the same keystream will be produced, you will find that there's a 3% increase in states that lead to the observed keystream after 100 clockings. So that means that if you find a hit, you find 13.4 states on average producing the keystream you were looking for. Or, put in other words, for every value contained in the tables, 13.4 real-world values can be cracked. > Still you have to backclock the result to get rid of the frame number > forward clocking step to arrive at Kc. So apart from the above optimization, > all the backclocking you have to do is in no-majority-clocking mode. > > Again, you do need to clock forward and backward in majority-clocking mode to enhance your table's hit-rate by a factor of 13.4. (or 13.0 if you skip the 3% trick) And as far as I know you never really arrive at Kc without some extra effort (namely: clocking the lfsr's to an empty state without the help of majority clocking) But, for the purpose of decrypting one connection, all you want to know is the lfsr state after clocking Kc in, so you don't really need Kc anyway. Cheers, M. _______________________________________________ A51 mailing list [email protected] http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
