Hi, I'm trying hard to get enough background information to make a balanced assessment if investing 2000 usd is worth the toy.
Some questions have arisen, partly relating to practical issues: - is it correct that the available table-torrents are currently only 100 gb in size, instead of the announced 2 tb? - am I correct that having only one USRP2 will let me only capture half the bandwith needed to get the full GSM 900 band? - if so, would this be a real problem in light of A5/1 decryption, or would I just have very degraded audio quality (i.e. only half the packets captured, considering channel hopping, and assuming that the hopping sequence is known) and slimmer chances of catching/detecting known-plaintext packets? - is it correct that the table-generation software as distributed will only compile / run / be of use for people having Cell or CUDA machines? I have loads of spare x86 cpu time and it bothers me I can't seem to contribute or experiment a bit. (and unfortunately those fancy nVidea things won't fit in every 1U rack server nor in a laptop...) and one relating to A5/1 itself: (http://reflextor.com/trac/a51/wiki/A5/1Basics) - If I understood the wikipedia page on A5/1 correctly, the algorithm gets Key+Frame Number as input and generates 2*114 bits of keystream, enough for one burst up/down. Am I right that this is not entirely clear, in that the algorithm goes on serving keystream bits for bursts following, without (ever) being re-initialised with a new Frame Number before the call ends? (otherwise I can't see why having the internal state lets you decode the entire conversation) (and, would in that case missing half the bursts (with only one USRP2) not put you at risk of running out of sync with the keystream when missing encrypted signalling data? or could you indeed predict, say, an hour of keystream ahead?) (and what is the Frame Number anyway, on what does it depend?) A lot of questions, I know! Kind regards, M. ps. I came across this paper: http://www.blackhat.com/presentations/bh-europe-08/Steve-DHulton/Whitepaper/bh-eu-08-steve-dhulton-WP.pdf = = = Once we run our 204 data points through the rainbow tables we should have on average 3 A5/1 internal states. From this we can load them into A5/1 and reverse clock it back to after the key is mixed in. Because of the majority clocking we'll end up with multiple possible state values at that point. After we reverse all 3 internal states, we look at the possible state values and the common value will be the correct one. From that point we can clock A5/1 forward to decrypt or encrypt any frame. It is possible to derive the actual Kc key, but at this point it isn't necessary. = = = "reverse clock it back to after the key is mixed in"? is this total nonsense (impossible/useless) or am I missing their point? _______________________________________________ A51 mailing list [email protected] http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
