On Wed, Jan 06, 2010 at 05:40:41AM +0100, M vd S wrote: > 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?
yes. the available data should be enough for the amount of known plaintext expected to exist in GSM. The tables will continue to grow. > - am I correct that having only one USRP2 will let me only capture half > the bandwith needed to get the full GSM 900 band? you can capture either up or downlink. the GSM900 band is 35 mhz wide, so you can capture nearly all of it with the software currently available, i.e. without filtering out unused ARFCNs on the FPGA of the USRP2. > - 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? this would be the case if you tried to capture GSM1800 with a current USRP2. you would only get a halfduplex dump of a connection and some bursts may be missing as they are out of the spectrum you just captured due to frequency hopping. > - 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...) there will be support for SSE, nvidia, cell and ati. SSE being the smallest of the family and the most power-hungry. > > 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) The A5/1 state gets initialized with Kc and the frame number at the start of every burst. Since Kc is constant for the duration of a connection and you can easily compute Kc from the A5/1 state, you can decrypt every burst of that connection after having brute forced a single A5/1 internal state. > > (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?) not a problem (see above). > > (and what is the Frame Number anyway, on what does it depend?) on the number of frames that get transmitted. the frame number is incremented with each frame and since it is 22 bits in size it wraps around after a few hours. it is transmitted in clear over the air periodically in synchronization bursts on the beacon channel, _______________________________________________ A51 mailing list [email protected] http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
