thanks ,so your suggestion is to capture SDCCH which goes from MS to BTS and use its 4-bursts as the source of known plain text . according to um interface wiki , SACCH is also sent on every call and it certainly has 4 bursts thus the know plain text which i saw it on the other papers too . can we use both of these sources to decrease the amount of tests we need to do ?
-- From: Sascha Krissler <[email protected]> Date: Sat, Oct 3, 2009 at 1:34 PM Subject: Re: [A51] known plain text To: a51 <[email protected]> > are we certain there is always 4 frames of known plain text available > thus we always have 204 known key streams ? is this documented this is not always the case. if you have receive errors then depending on whether you know at which bit they occur 1) you do not know where but how many: you would have to do 2^n * 204 lookups (n == number of flipped bits) 2) you know where: 2^n lookups (try both 0 and 1) so 1) makes the capture attempt practically impossible. another case where you do not have enough plaintext is when the network changes the message format, e.g. include some optional information elements in a message or pad the message with random data instead of 0x2b 0x2b 0x2b. whether this can be done and is done is beyond my knowledge. > somewhere ? are we always having SACCH data available ? which side of we are sucking data out of the SDCCH during call setup. > the traffic , up link or down link ? to my understanding this attack there is a CIPHER MODE COMPLETE message that is sent from handset to network whose plaintext can be guessed completely. > is based on dividing the whole key space to the amount of known key > streams , is that right ? so can we use different sources of known > plain texts and put them together ? for example i see there is also this is true. a simple division. > known plain text in LAPDm , and maybe in other places . is it the CIPHER MODE COMPLETE is an LAPDm frame. there are certainly many spot to extract known plaintext and since each LAPDm frame is padded, once the padding is 6 bytes large, you get a whole burst with 114 bits of known keystream, allowing for 51 lookups. you could also work with say 60 bits of known keystream and guess the missing 4 bits, where you would need to do between 1 and 16 lookups, 8 on average, till you find a Kc value that decrypts the other traffic. > possible to put them together somehow ? is there a list know known they have to have 64 bits of consecutive plaintext. i once saw somewhere another method taking advantage of FEC which uses known bits in other patterns which i did not try to understand (found in the 2003 paper) > plain texts of the algorithm ? and finally , those known 4 frames > should be continues in the real traffic ? sorry to ask a lot of they have to be continuous in the SDCCH since they are the 4 parts of an LAPDm frame. > questions . i'm learning :) > all the information is second hand and i did not verify it with experiments. ________________________________________________________________
_______________________________________________ A51 mailing list [email protected] http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
