I tried to do some timing on how long it takes to calculate / lookup chains with more distinguishing bits. Currently tables are calculated with 15 zero bits at the termination point. But I discovered that there seems to be a limit to how many 0 bits A5/1 is capable of generating in a row. ( Around 20+ bits ) - It could be that the only way to get longer runs of 0, is to have all 0 bits in the lfsrs. This is a degenerate state that doesn't occur in key-setup.
The distinguishing bits generalization that we use is somewhat flawed. In my test runs, I eventually had to place the bits in a pattern like: (hex): 0f0f0f0f0f0f0f0f Ex check ( output & 0x00070f0f0f0f0f0fULL ) == 0UL etc.. Just checking on the lowest consecutive bits made the chain searching non-terminating. In other news, building the A5 grinding code as a C dll, made it really easy to add python bindings (ctypes) .. It would be nice to have a clean python front-end, rather than trying to emulate a weakly typed language through a maze of templates :-) Frank _______________________________________________ A51 mailing list [email protected] http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
