Ramarathnam Venkatesan: Today it's a great pleasure to have Orr come and give us a talk on attacking KASUMI. As you all know, Orr is really well-known cryptanalyst and these a student of Eli Biham, and he has broken every symmetry crypotosystem in sight, including AES, IDEA, and now keelog, and now today KASUMI. Always a pleasure.
>> Orr Dunkelman: Thank you very much. Okay. So I'm going to discuss a practical-time related key attack on KASUMI, which is a block cipher used in a
3G networks and GSM networks actually as well. And this is joint work with
Nathan Keller and Adi Shamir, who will correct me if I make any mistakes around. Which is very expected.
So roughly going over what we are going to have. First of all a bit about GSM and 3G standards. I'm not GSM/3G standard expert, so if I say something that contradicts the specs or your knowledge, you're probably right. This is just guessing from -- I will discuss this issue in a second. Sometimes both of us can be right. I mean, what I'm saying and what you know can be right because there are so many standards running around in this world.
>>: [inaudible].
>> Orr Dunkelman: No. I will just speak about it. I don't want to put it on sites, especially if they are going to be broadcasted to the whole world.
Then a bit about the Boomerang Attack, what's differential cryptanalysis, so sort of one-on-one introduction to cryptanalysis. And then the Boomerang Attack which is improved or more generalized approach. And independence assumptions submitted in the differential cryptanalysis and Boomerang Attacks and actually to some extent our result can be summarized as sometimes there is dependence and we can use it for our advantage. So if there is one slogan that you can take with you home today besides KASUMI is broken is that dependence might help you.
I will discuss the San wish attack and I will show you the new attack on KASUMI and we will conclude the talk.
Okay. So 3G/GSM, more than 3 billion users around the world used to mobile phones which are either in 3G or GSM. And it's actually used in 212 countries, which is more countries than the UN has, just to give you the indication of where we're standing.
>>: [inaudible].
>> Orr Dunkelman: Yeah. That's -- now, it doesn't inherent support for roaming, so if you cross the border here to Canada, you can continue speaking, even though it would cost you arm and a leg because Roger's takes quite a lot of money. And it has actually GSM which is the second generation communication

has four bandwidths, four bands, 900 and 1800 in all civilized world wee sides
North America and Chile and 850, 900 in North America and Chile.
Do you to historical political reasons. Nothing to do with really issues. The three network use 1700 and 2100. Surprisingly enough this is for dialing downlink, this is for uplink. So they just changed the model completely. You will see it in a second.
Now, again there is a chance in contradicting myself. The problem is that half of the documents about 3G and just to give you some indication about the protocols around here, there is GSM, which is second generation, there is GPRS, which is the GSM approach to send. It's General Packet Radio Service, which is the second and a half generation. Then there is 3G and UMTS, which is the
Universal Mobile Telecommunications System. Another is the high speed data something something, which is three and a half. And soon they are going to have 4G, which is again UMTS.
So just to confuse they use -- there is GSM 2.9 and GSM 3.9 and there is 3.99 and 3.95. So probably --
>>: [inaudible].
>> Orr Dunkelman: And one of the specs I'm right. Okay. Just to give you some indication about the speech related to it in GSM, voice is encoded either in six and a half kilobits per second or 13 kilobits per second. This is the outcome of the encoder. The data in GPRS can reach 144 kilobits per second, which is nice.
It's sufficient if you don't do much on the network. And the space is actually the same uplink and downlink. And 3G will improve the low quality of the voice and of course they will reduce the high quality of the voice in exchange. Sort of karma thing. You have to balance everything all the time. And you can keep up to two megabits per second and three and a half I think you can reach 21 megabits per second. And so far everything is symmetric.
When you get to the fourth generation, it's going to be for the first time asymmetric where you will be able to download faster than you upload. Thinking about the fact that users most of the time want to consume information, not to generate and share information.
>>: [inaudible] want to watch 10 movies at the same time?
>> Orr Dunkelman: You're going to connect it to your laptop and when you're going to [inaudible].
>>: [inaudible] laptops [inaudible].
>> Orr Dunkelman: And then you will connect this laptop to the clouds and it will start running secure multiparty computation protocols and location based services [laughter].

Yeah. And most of it is of course going to be protected and secured with various mechanisms.
>>: The asymmetry is not -- doesn't have to do with sort of basic technical occasions like the powers of the transmitters versus the power of the phone?
>> Orr Dunkelman: It's most -- in theory you could increase the battery size by factor of two and it should still work.
>>: Right.
>> Orr Dunkelman: It's a matter of just we don't have enough bandwidth.
Currently most service providers, mobile service providers have an issue with lack of bandwidth. To their base stations. This is currently the inhibitive factor in many cases. And in the future it's going to be even worse. So God knows why they want to give you more megabits per second between you and the base station. Well, they cannot push enough information to the base station as it is.
>>: [inaudible] may become a virtual reality [inaudible].
>>: Why don't we let him continue.
>> Orr Dunkelman: Well, I have the feeling that at the end this is going to be the case. Nobody would ever go outside this house. Good for your muscles.
Okay. So let's consider for example this lovely thing, handheld device and it's best to be security. So what are the most interesting security threats? Call theft and old analog phones and old generation protocols have quite a lot of issues with call theft or cell phone duplication where you just leave the phone for a few seconds, you read all the information from it and now I can make phone calls and charge your account rather than mine.
Also there is the issue of eavesdropping. And today we have way more issues and today there are even viruses for mobile phones and that sort of stuff. Please go to visit my website using your new third generation mobile phone. Very cool viruses. Seriously though. The GSM/3G [inaudible].
>>: The [inaudible] your iPhone.
>> Orr Dunkelman: Yes. This is an example for how to use the fact that you have 100 megabits per second per download. I mean, if you want to break stuff that's important.
Now, the model is very simple because we have service provider and we have customers. So we can have preshared secrets. And to deal with all these issues there is a SIM card inside each mobile phone which works in GSM or 3G which contains a series of preshared secrets. And that's it. That's the only source of security and the fact that they used proprietary algorithms. Gives you this warm fuzzy feeling that it's going to be secure.

Okay. So what are the protocols? First of all, you have to authenticate your mobile phone to the network. And there are two protocols, A3 and A8 which are actually not defined. A3 and A8 are carrier protocols, and they are defined to be
I send to the mobile phone query of this and this many bits. I get a response of this and this many bits. I do -- I send again this and this many bits, I get this and this many bits. And at the end of this process I know that the mobile phone at the other side is instead one of the mobile phones that I authorized, actually one of the SIM cards that I authorized. And, by the way, we also have a shared key.
This is a biproduct of all this authentication protocol. And the end of this execution you get either 64 bits of a key in GSM and A5/3 and in the future you'll get one of 28 bits and this is also what you get in 3G networks, 128 bits of shared key based on 100 --
>>: [inaudible] out of the 64 bits you get [inaudible].
>> Orr Dunkelman: It's already [inaudible].
>>: [inaudible].
>> Orr Dunkelman: Out of the [inaudible].
>>: Not recently. Not recently. They've [inaudible] the last few years.
>> Orr Dunkelman: Well, the cool thing is that A3 and A5 are not defined, so there is a sample example called COMP128, and if you have heard this name before you should probably know by now that when Goldberg and Wagner in '98 reverse engineer the protocol for just reading the begin they already block A3 and A8. Which was very common. Today people use COMP128 2 or other protocols and so far nobody complained too much. And the reason for that is well, we don't really care. You will see in a second.
The other part and the part that's interesting for us as the users is our privacy, our precious privacy. When you go into the train or the bus and you start shouting at your mobile phone you don't want people around you to eavesdrop.
How do we do that? We encrypt the information going from the mobile phone to the base station and only to the base station. From the base station to the rest of the network, it's unencrypted. So if, for example, you are working for a government agency and you want to eavesdrop to some conversation, you don't have to run after the guy, just sit at the center of the Verizon or any other mobile provider and just listen to the conversation. It's unencrypted there. Yeah?
>>: You ignore 85/0 which is even weaker. You don't consider that?
>> Orr Dunkelman: I will get there. Don't worry. So the if earlier attempts were
A5/1 and A5/2 which were stream ciphers. A5/1 accepts 64 bits of key, usually
10 bits of these are set to zero, and A5/2 also accepts the 64 bits. And they are not very strong.

How now strong? Well, when A5/2 was first reverse engineered by I think it was
Goldberg, Wagner and Brineko, they already published an attack of --
>>: [inaudible].
>> Orr Dunkelman: Briceno. Sorry. It started with a B.
>>: [inaudible].
>> Orr Dunkelman: So they succeeded to break the cipher into the 17 operations. Which is roughly a few seconds if you don't really know how to program. And A5/1 had several other issues. And besides these, there are also
-- the results are very specially stream cipher called A5/0 to be used where encryption is really bad, and it accepts zero bits of key as input and produces zero bits of key as output to be used in France. [laughter]. It used to be the case.
>>: [inaudible].
>> Orr Dunkelman: No, it used to be mandated.
>>: [inaudible].
>>: Most phones are [inaudible] whether you are encrypting now or not. There was one model that was made by I think Simmons which could be set into a mobile that will display. Now, if you go anywhere in France it will usually encrypt using A5/1. If you go into Paris the [inaudible] that's encrypted disappear and is still the asleep. [inaudible].
>> Orr Dunkelman: Yeah, but it's Paris. I mean, everything is public domain anyway. [laughter].
The thing about these ciphers besides being weak, we'll see in a second how week they are, is the fact that the design was kept secret and had to be reverse engineered even though you know as usual in cryptographic circles there were leakage, you know, over the years and people started to say, hey, I know there are 64 bits of registers running around there, and there are three registers and slowly people actually work in deciphers even before they were public knowledge. A5/1 can be used in all modern countries, western countries. A5/2 is to be used in countries where the American secret services and the French secret services wanted to eavesdrop. That means Russia, third world countries,
Middle East, et cetera, et cetera.
>>: Including Israel.
>> Orr Dunkelman: Including Israel. Israel still uses A5/2. Best cipher around.
[laughter]. In the next generation of GSM, two and a half or three, they're already using KASUMI, which is a block cipher, which is the entire source of this talk.
And it is used in two modes of operation. One of them is F8 as for encryption and F9 for authentication. So it's you take the same block cipher, you throw it

into some sort an authenticated CBC MAC, authenticated CBC MAC and encryption, some sort of structure.
I think one of the reasons they designed everything from scratch is just to prevent issues with IP. So if you develop everything on your own, you're secure against the problems.
>>: [inaudible].
>> Orr Dunkelman: Huh? You're supposed to. In any case, A5/1 first attack on the real cipher was by Biryukov, Shamir and Wagner, 2000. Then there was some attack by Matt -- sorry MJB, it's Maximal, Johnson, and I'm terribly sorry. If your name starts with B, I keep on forgetting that.
And then there was Biham and Barkhan from 2006. You can break to the A5/1 in about two to the 30 something operations, or if you give me some data, I can do it even faster. So it's relatively prone. A5/2, on the other hand, which is much better, while -- once it was reverse engineered in '99, it was automatically broken.
But there is a very nice attack by Biham, Barkhan and Keller from CRYPTO '05 where they just recompute a table -- there is some table of 2 to the 17 to precompute. And once you precompute it, you get the data from one packet of information you apply -- you multiply it by a metrics two to the 17 times, you check some parity code and once you succeed, you finds the key in -- I think this is just a key. I mean just using multiplication by metrics. You can do it in less than a second.
And recently there was some -- somebody who built tables for A5/1, the
[inaudible] project of rainbow tables for A5/1 and at the end of it, you know you have rainbow tables, which is really cool. You can do it with one packet, also, of information. And some def and def [phonetic] bytes of information. And then they said well, you know, if you need to attack A 53, you just ask the mobile phone nicely, can you please switch to A5/1.
So actually the protocol describing which cipher to use is not authenticated. So if you have a mobile phone working in A 53, I can go to your mobile phone and tell it change to A5/1 because I know how to break A5/1.
Now, the cool part is that this is actually appearing already in the CRYPTO 2005 paper when you can ask it can you please switch from A5/3 to A5/2 because it takes less than a second to break you in A5/2 and I need rainbow tables for A5/1.
So you if really want to attack A5/3 ciphers, go to A5/3 crypto system, just go to it, ask it, can you please switch to A5/2, get the key, it's the same key in all
[inaudible].
>>: [inaudible].
>> Orr Dunkelman: I saw your question. It's the same question. Not -- it's even worse.
>>: That's a great idea.

>> Orr Dunkelman: A5/3 uses KASUMI. KASUMI as you will see in a second accepts blocks of 64 bits and keys of 128 bits. There is only one problem. The standards say that at the end of A3 and A8 -- yeah, up to this generation you get
64 bits of a key. But you need 128 bits, so you just copy the one 64 bits, duplicate them and whoala, 128 bit key for free.
Anyway, there was some theoretical attacks on KASUMI. We published them in
CRYPTO '05. And now at some point A5/3 became A5/4, which is KASUMI, the same mode of preparation that now supports 64 bit -- 128 bit keys. When you use it in the 3G networks, the same algorithm A5/4 is called user authenticated encryption one. Everything is the same.
And now there is is the UAE2, which is based on SNOW3G, which is a stream cypher, accepts keys of 128 bit designed by Yan Song Ital [phonetic]. Actually a good cipher. So far nobody knows how to break it. And the GSM/3G corporation just announced that they are going to introduce UAE3, which will be based on some Chinese cipher called ZUC. Happens.
>>: Has it been published?
>> Orr Dunkelman: Actually, the description was recently published and in the cryptogram session people [inaudible] asked on behalf of this corporation for people to actually break ZUC so they will not have to implement it. I think this was not an official requirement, but I mean --
>>: [inaudible] push by the Chinese government [inaudible].
>> Orr Dunkelman: Yes.
>>: [inaudible] algorithms.
>> Orr Dunkelman: It's going to be just like SMS all over again. Now, I have to give some credits to Anderson from '94 and Golish from '97 who actually broke
A5/1 before they knew what A5/1 is. They did it by just saying okay I have this and that many registers, that many sizes, you guess this, you do that. Sort of a random black magic.
So quick overview of F8 and F9. You know, there is a mode of operation. We have to the prove that it's indistinguishable and de-Frenchible, very secure that you don't lose security because you're using crazy modes of operation. F8 was proven to be secure in the paper from 2001. And in the paper from 2003 it was shown that F9 is also secure MAC.
Assuming that the underlying block cipher KASUMI is a secure pseudorandom permutation. Everybody here happy?
Good. Actually what Iwata and Kohno showed in 2003 is that these proofs were wrong. But Iwata to the rescue. He proved in 2004 that if you assume that the block cipher is secure against related key differential attacks, then F8 and F9 are

secure. So as long as the adversary cannot break the crypotosystem when he's allowed to pick two keys and control the actual difference between them, F8 and
F9 are secure. Others, well, you lose insecurity. Yeah?
>>: [inaudible] specifically for the actual differences.
>> Orr Dunkelman: Yes.
>>: Or any [inaudible].
>> Orr Dunkelman: Actual differences. This is in the proof. The reason for that is that they actually use the same key in F8 and F9 and they -- the standard way to transfer one key into two keys is you XOR it once with one constant, once with a different constant. I see Josh trying to -- this is -- there are standard tricks.
How do you transfer one key into two keys?
>>: Unfortunately for us [inaudible] is not what we need in our [inaudible].
>>: So then you [inaudible].
>> Orr Dunkelman: They were anticipating it. Okay. A bit about KASUMI. So actually it's a descendent of MISTY. There was a block cipher designed by
Mitsuru Matsui named MISTY1. 64-bit block, 128-bit key. It's a Feistel gesture with a diagram. So this is a Feistel construction. You take 32 bits you throw them here, 32 bits go here. Each round they iterate two round functions the FL which is given the key in linear function. But when you don't know the key, well, it's still a linear function but you don't know which of the linear functions.
And the FO which is in if Feistel like construction of three rounds using FI which is in itself Feistel construction or four rounds. It's sort of a.
>>: A [inaudible].
>> Orr Dunkelman: [inaudible].
>>: Actually it's a very large number of [inaudible] you count the [inaudible].
>> Orr Dunkelman: When you look at it, it's very secure. If you try to go with any differential going from this side to this side you're going to get completely cooked.
In any case, the interesting thing is that FL and FO switched the order. In the old rounds it's first FL and then FO. Otherwise it's first FO and then FL. Just to make things even more interesting, after eight rounds of this thing, you get the outputs. And it was a great rejoice in the camp.
Questions so far?
>>: So can you describe what this Feistel is more rounds or some [inaudible].

>> Orr Dunkelman: Not really because you cannot really do that. There are eight Feistel rounds. You can treat each of these as some random permutation, independently random permutation and you have eight rounds of the Feistel.
That's it.
>>: [inaudible].
>> Orr Dunkelman: Yeah, but they are all on the same data pass. That's the -- so actually each value here is four times the stuff that comes. It can be completely random. For the sake of argument, assume that this is a perfect random -- even random function. It's a permutation. But assume it's a random function. You have all the [inaudible] rack of super pseudorandom permutation after four rounds everything is fine when there are eight rounds. Actually we are using these [inaudible] bits.
>>: Are you saying it would have been much better off if you had done just two dozen real Feistel rounds instead of this MISTY Feistel?
>> Orr Dunkelman: Depending on what you define as real Feistel rounds. They might have been better. Okay.
So here is summary of attacks. So far --
>>: Just picture this guy both MISTY and KASUMI [inaudible] schedule.
>> Orr Dunkelman: This is not in MISTY. This S7 does not exist in MISTY.
>>: Yes, that's one big difference. But also the key schedule is different.
>> Orr Dunkelman: The key schedule is different.
>>: When you talk about this. And the point is that the original MISTY as of today still has how many, 28 bits [inaudible].
>>: [inaudible].
>> Orr Dunkelman: There's a slide at the end. This is a great question. I have a slide. The interesting part about the key schedule algorithm, they transfer the key schedule from MISTY1 which was highly nonlinear to something which is linear. You take the key, you XOR it with a series of constants and then fast generating 256 bits of key, and each round you use 128 bits of subkey material, which is linearly derived from the key. And it's always the same in the sense that this KO in the first round it comes from the first word of the key and the second round it's the second word of the key, third word of the key. There are eight
16-bit words and each time you use all of them in each round.
One 28 bits of subkey each round. Lots of fun. But luckily everything is linearly dependent. So distinguishing attack on four rounds from 2001 you can attack up to Securities and Exchange Commission rounds using two keys in the same related-key differential attack. Impossible differentials can do it with one key. Up

to six rounds in 2 to the 55 chosen plaintext and 2 to the 100 time, a work from
Kuhn from Euro CRYPTO '01.
And then we have a series of related key Boomerang and key rectangle attacks that could break the entire cipher in 2 to the 54.6 chosen plaintexts and 2 to the
76.1 time. So you know the standard theoretic cryptanalytic game, game is over, cipher is broken. Who cares?
Luckily for us, we can use new techniques, reduce the data complexity to 2 to the
26 and the times 2 to the 32. I hope it's impressive.
Okay. A quick introduction to differential cryptanalysis. How many of you ever her about differential cryptanalysis?
>>: [inaudible].
>> Orr Dunkelman: Yeah.
>>: [inaudible].
>> Orr Dunkelman: I know that the people from three fish never certified about that. [laughter]. I have the feeling that this talk is going to be rated not PG 13 but non cryptographic audience only.
Anyway, so the work is a work by Biham and Shamir and is going to be presented on the slides quite a lot. Instead of looking actually at the development of the encryption of one value you look at differences. You look at two values, you look at how the difference which is usually going to be the X develops through the encryption algorithm. Why this is interesting? Assume for a second you have this simple operation. When you take the key and you X it with some data. Now, if I have two inputs, X and X star and you throw them in through the same situation, on one hand I'm going to get X, X or K and the second value is getting to be X star, X or K. But when we look at the extra of these two values, the K disappears and they get X, X or X star.
So if I knew the difference before the operation, I will know the difference after the operation which would allow me to throw away the key and disregard the key.
And this is the best thing you can do in cryptanalysis, just throw away the key.
Of course I'm kidding. But the chit comes from the fact that now you cannot handle nonlinear operations. I mean, you can go through all the linear operations if you are know the difference before a linear operation you will know the difference after a linear operation. The same goes for fine operations. Nonlinear operations on the other hand you cannot do.
What you do, you actually approximate these nonlinear operations using probabilities. If I had this input -- the difference I will have this -- the difference with def and def probability. Instead of discussing values or differences you can scuff the probability distribution of these differences.

So three comments about differential cryptanalysis. The comments that we will need in mind first of all is differential description. This is a prediction on all the differences each and every round. If you start with this difference after one round you will have this difference with this probability, after two rounds it's going to be this difference with this probability and so forth.
And differential. It doesn't really matter how I get from here to my hotel, as long as I get there. So it's input difference, output difference and the probability to get from point A to point B. That's it. So far so good? And of course the probability of a differential characteristic is the multiplication of all the probabilities of the differentials along the way.
>>: [inaudible].
>> Orr Dunkelman: Great comment. I have a slide. [laughter]. And the probability of the differential is the sum of all the probabilities of the differential characteristics that share input and output. And there is the concept of right pair, which is a pair that satisfies either the differential or the differential characteristic, depending on what I'm trying to do.
Now, generally speaking if you want to -- if you have a differential or differential characteristic with probability P, you need about one over P pairs which satisfy the input difference. Question so far? This is just your metric distribution. If the probability of succeeding is one percent, you have to try about 100 times until you succeed. Okay.
So how does the differential attack works? You take many, many pairs. One of them, at least one of them has to be a right pair. You try to identify the right pair and then you analyze it. And why do you gain information from right pairs? The pair that satisfy the differential characteristic or the differential gives you information about what happened inside the nonlinear operations. So it gives you more information about what's going on inside. And usually you could use this information to find the key. Now, the exact analysis depends whether you're using differential or differential characteristic. It depends if you're attacking the number of rounds of the differential or more rounds. You can do what is called
NR attacks where you try to attack more rounds than there are in the differential.
And there is also distinguishing attacks where you can tell this block cipher is indeed eight rounds of AES or this block cycle is not eight rounds of AES. So that is what you do. And that's it. Questions on differential cryptanalysis? There will be exam at the end.
Okay. Let's move to Boomerang Attacks now that we have differentials and we know that the differentials are really, really bad for you, unless you are attacking.
You design the block cipher such that it will be secure against differential cryptanalysis. How do you do that? You make sure that there is no differential with probability more than let's say two to the minus 110 in your cipher. Because then that means that you need two to the 110 pairs that satisfy the input difference in order to find one right pair and so this is the way to build secure ciphers.

And at some point people started to have very long ciphers with very nice proofs of security. And what Wagner had to do in '99 was to actually try to break such ciphers. So assume for a second that you have a very long cipher, no good differential for the entire cipher. However, if you cut the cipher in half, you have a good differential to the first part, good differential for the second part but they don't combine. So the Boomerang Attack is a way to actually combine it. And the idea is as follows: Assume that you have a differential, alpha goes to beta in the first cipher, in the first half and gamma goes to delta in the second. And for the sake of argument, assume everything happens with probability one. It makes life easier.
So we start with plaintexts P1 and P2 with --
>>: [inaudible] otherwise you could [inaudible].
>> Orr Dunkelman: Yeah. Beta is different than gamma. If beta is equal to gamma, everybody here happy. Besides the designer of the cipher.
So if you start with alpha difference and you partially encrypt, you will get better difference. Again, everything probability one. That would be great to stop here but encryption continues. So X1 becomes C1, X2 becomes C2. Great.
Now, let's do the Boomerang magic. If you take C2 an extra delta to it, you're going to get C4. Now, when you decrypt C4 and you get X 4, you're going to get a gamma difference here because gamma went to delta with probability one and using regular differentials everything is symmetric. It doesn't matter if you go downwards or upwards, backwards or forwards and you will get gamma difference here. And if I will do the same thing with C1, I will get here C3, which will be decrypted to X3. Again, gamma difference.
Now, the interesting part is that X3 and X4 satisfy a very interesting relation, which is difference gamma beta gamma. The gamma cancels out and the difference here is beta.
Now if I have values with difference beta here they will go back to two plaintexts here with difference alpha. If there are probabilities involved if the probability of this step is P and this step is Q then the total probability is P squared and because you have to satisfy both differentials and Q squared -- times Q squared because you have to satisfy two differentials at that point. Okay. This is the
Boomerang Attack.
And you can do it with related key differentials as well and not entering into too much details about what's the related key differentials are, you're just allowed to tweak with the differences in the key. Remember the proof of security if the difference are exactly the seam, you can do the same with related key differentials. It's a bit tricky with the relations between the keys, but if you select everything correctly, everything is fine. Okay.
>>: Is that the same as [inaudible] same one [inaudible].

>> Orr Dunkelman: No, it's actually BBK over 5. It's euro CRYPTO '05. There is a paper from -- this is C05 which is submitted in parallel and this is [inaudible] from ACISB 04 if I'm not mistaken, who actually submitted it to a conference that nobody heard of. So this is two keys and four keys and four keys and 256 keys.
Okay.
Okay. So the small technical detail about differential cryptanalysis is the fact that we assume that stuff works. Which is usually the case especially when you have an attack of two to the 100 complexity you assume it works. And the reason for that is that we don't really know to deal with things otherwise.
So assume for a second that we define a set of all the good values for some differentials. So if you have a differential alpha goes to beta I'm just going to capture all the good values. And I'm going to pick one of the two in the pair. It doesn't really matter. If you want to formally define it, I mean both P and PX and alpha are in this set meaning if P is in GK of alpha goes to beta, that means if you CRYPTO P under K and PX or alpha under K you will get beta, difference in the output.
And now you can almost immediately see how can I use differential capacities in attacks by identifying in which of the sets GK I am, I can tell you something about the key. Because it's not the same plaintext which is in all the sets. Most of the time it's going to be this plaintext in this set and this plaintext in this set. So by identifying which of the values is the right pair you will identify in which set you are. And you can define the inverse of the set for the ciphertext.
Okay. Now, the reason they are not underlying assumption about the probabilities when you define the probabilities of differential characteristics and this is what I mentioned before, if you're trying to predict the probability of the differential for many rounds we usually assume it's the multiplication of all the probabilities for each and every step under way, each and every round. And you have to assume that these actually are independent of each other, that the event
-- assume for a second that you have a differential alpha goes to beta goes to gamma, and you ask yourself what the probability that alpha goes to gamma, you have to assume that the set of the good ones with respect to alpha goes to beta is independent of the set beta goes to gamma, then the probability is just a multiplication.
Now, another independent assumption which is used in attacks --
>>: There are cases in which you don't need this independence assumption.
This is when you are [inaudible] and you independent subkey after the end of the
--
>> Orr Dunkelman: Amazingly good comment. This is something related to actual key recoveries that most of the time -- and this is something for people who don't do cryptanalysis, we find the distinguisher for seven rounds of KASUMI and you want to attack eight rounds. The standard way to do it you partially try all the subkeys of the 8th rounds, you partially decrypt. If the decryption was

correct, you're going to get seven rounds of decipher which is distinguished from random.
If you use the wrong key, then it's as if you added another layer of encryption, another round. And then you expect it to be closer to random because it's more probable -- most of the time, it's more probable that seven rounds are closer to seven rounds nine rounds are closer to seven rounds. Most of the time. There are very specially cases when you can screw up this independent assumption, but I think it's a legitimate one.
Okay. So actually we can look at cipher where all the subkeys are independent of each other. If all the subkeys are independent from each other then indeed the probability of one value being in the right set for the first set is independent of it being in the second said and et cetera. Now, for such a cipher --
>>: It's only when you are [inaudible].
>> Orr Dunkelman: Even if you are adding -- as long as you are covering -- as long as you are mixing the key correctly and you don't screw up too much, I mean don't multiply by the key. But as long as you are adding or XOR and you can transform any value to any value, you are fine. If the probability of transformation much any value to any value by the subkey operation is uniform, life is great. Life is good actually. Great would be when you really break the system.
Now -- sorry?
>>: [inaudible].
>> Orr Dunkelman: Sorry.
>>: I didn't get the Markov chain. Why [inaudible].
>> Orr Dunkelman: Because then the -- each step, each transition is independent of previous steps. Because what happened previous is independent -- if each time I add in -- I transform the value to a randomly chosen value --
>>: [inaudible].
>> Orr Dunkelman: If all the subkeys are independent then each step is independent of all others.
>>: That's true if you -- yeah, I think there are exceptions for [inaudible] if the key's only in part of the function, something like that. But it's [inaudible] where you the home key.
>> Orr Dunkelman: Yes. You have to [inaudible] everything even if [inaudible] networks if all the subkeys are independent you can still get it from a different point of view. Let's say even in DES, this assumption works. So there are ways

to build counter examples. I will be -- I will submit. But if you know the ways, you probably know what I'm going to say next. So please on behalf of the people who get completely confused by that, including myself.
Okay. Now, the [inaudible] is that how the analysis work? I pick a plaintext at random. I picked the key at random. And then the probability that this plaintext or this plaintext pair will satisfy the differential is need the multiplication of each and every step on the way. But usually the adversary goes to the device.
Please be kind enough to encrypt me, this plaintext, this plaintext, this plaintext.
The key is fixed once. So actually we were cheating because the key is not fixed after fixing the message and for each message it's chosen independently. We fix the key once, and therefore we need to assume some sort of a stochastic equivalence which means that it doesn't really matter what's the order of preparations. Either you first pick the key and then pick the plaintext or first pick the plaintext and then fix the key, it should be okay. Most of the time it is.
However, there are cipher where this is not the case. Usually this gives rise to issues with wikis keys for which the behavior is completely different than usual, idea is a notorious example of cipher with lots of related key issues.
On the other hand, you can construct something that is called conditional differentials. This differential works if key big is equal to zero. So there are lots of issues running around there. Most of the time, most of the ciphers this is the case. You can assume it without making too many mistakes on the way.
For the Boomerang Attack the situation is much more complicated because we actually have two differentials in four pairs. And it might be the case that this pair is independent of this pair but they are dependent with these pairs because there are four values here, each is used in two different pairs with respect to two different differentials, so the entire independent assumptions that you need to assume are much stronger, so roughly speaking, you need to assume that the fact that this value is part of a right pair does not prevent this value from being the right pair with respect to this differential. This differential, the second differentials. And this does not affect the third pair. Yeah?
>>: Would be okay here, right, it's just you don't want negative dependence between these [inaudible].
>> Orr Dunkelman: The independence assures us it's P squared Q squared.
>>: Right. [inaudible] might be lower.
>> Orr Dunkelman: Exactly. I will be very happen if it would have been higher I would actually be very happy if it was zero as well. If you could prove that it didn't work, there is a variant of the Boomerang Attack called related -- sorry, the impossible Boomerang by [inaudible] which uses the fact that something happens with probability zero. So this is the formal definitions of what we need.
Not very interesting. And here is a counterexample.
Let's assume for a second that the first differential has alpha goes to beta one specific value of beta with very high probability. Let's say half. And the most

significant bit has a difference zero in it. And not only that, it has to be -- the actual bit has to be zero. If the actual bit of the value is zero, then the pair is part of the -- of a right pair.
Now, if what comes up from the bottom part is a differential with the most significant bit equals to one, it won't work because one pair succeeds, the other one cannot succeed. So you can give it formal definitions that say, you know, the thing is that Boomerang Attack can use many differentials. In the first cipher, in the second cipher. So you have to construct the example carefully. But you can show and construct very nice examples. And there are also more delicate examples if you follow the differential capacities where you make sure that something happens for the difference -- something goes through the same S book twice with four different values that cannot all coexist in the coherent manner. And if you want the full details of this example, there is a very nice paper by Shaun Murphy where he shows on DES a real cipher, he didn't -- you know, I can cook example. But he took DES and he showed a four round
Boomerang that doesn't go back -- doesn't come back. And the name of the
Boomerang is because you take something, you throw it, it comes back to you.
And if it doesn't come back to you --.
Now, to some extent if you use multiple differentials the problem tends to shrink.
Because if it didn't work with this set of differentials it will work with this set of differentials. And the thing is that usually there is sort of a karma thingy going around if -- there is in theory all the sets if there is the positive dependency in someplace you're going to get negative dependency in the other place and vice versa. Because the sum of all probabilities is one.
So if you lose something here, you must gain something there. So in the grand scheme of life, everything should be okay.
>>: That's not systematically key dependent.
>> Orr Dunkelman: Yeah. That's the thing. You have to -- I wouldn't say pray, but you have to accept the fact that, you know, the gods might be playing tricks with you or the NSA, depending which cipher you're attacking.
>>: [inaudible] is it possible to [inaudible] the relationship for this Boomerang
Attack like just mean on the board what [inaudible] plus [inaudible] I mean, what is the relationship? I mean this [inaudible].
>> Orr Dunkelman: This is the probability -- everything is independent. This is the probability if you have one differential who is probability P and one with probability Q.
>>: Yeah.
>> Orr Dunkelman: And the P squared Q squared comes from the fact that you use the same differential -- you use each differential twice.

>>: I'm just curious, what is the relationship that you get. You take a -- I mean, what is final attack [inaudible].
>> Orr Dunkelman: Okay.
>>: [inaudible].
>> Orr Dunkelman: That's a good question. So if you start with two plaintext with alpha difference and you process this process, you're going to get here two cipher -- two plaintext with the same alpha difference.
>>: I see. So you start these two plaintext, you get the same -- you get the ciphertext, the difference is [inaudible] but doesn't matter, you just have the same thing and there [inaudible] so you delay -- I see. [inaudible] I was just going to say is that initially it seemed to me that the time was just another way to prove a standard differential. But you're saying there is no standard differential in the relationship.
>> Orr Dunkelman: No, because beta is different in gamma, then you cannot connect them together.
>>: I see.
>> Orr Dunkelman: If you could have connected them together, it could be fine.
It's not always that fine. Anyway, as I said, it is sort of karma. If you lose someplace, you win some other place. And here is an example of the bright side of dependence. Assume for a second that you have alpha goes to beta and the last round of the differential characteristic is delta X getting to delta Y. And when you have on the backward direction delta being decrypted to gamma you assume you have a zero difference here on the right hand side.
And this is an example. So let's assume for a second that we have a pair of values. XA and XB which are being encrypted. There is delta X here, delta Y here. They satisfy the first differential characteristic. We are very happy.
Thrilled to say at least. And the encryption continues. And then we generate two new values, XC and XD coming from the bottom up using the delta differences going up. Okay. There is a gamma difference between XA and XC and between
XB and XD, but this is in a second. Which means that if you put XC here, you're going to get YC. And the interesting part is that the difference between XC and
XA in the right-hand side is zero meaning this is XA. I will do the animation again. It works. XA, so you're going to get YA.
The same goes for XD and XB. XD becomes YD, but actually this is XB which goes to YB, which means that if you look at what you have here is XA, XB going to YA, YB, delta X, delta Y.
So no matter what's the probability of this transition going down, you're going to get it for sure at this size even when you're dealing with XC and XD. Okay?
Always look at the bride side of dependence.

So this allows us actually to protect the cipher into something which is a bit more complicated on one hand. On the other hand, it allows us to do a better analysis of what's going to happen. So we have a differential alpha goes to beta here for the first cipher. We have gamma goes to delta in the second cipher. And there is some sort of transition in the middle where you get two values here with beta difference. You get two values here with gamma difference. And you ask yourself what's the probability of getting beta difference here?
The interesting thing is that if delta X went here to delta Y, it didn't matter which delta Y it was. Even if this delta Y was not a delta Y of the differential characteristic, some other delta why we don't care because it's going to be cancelled here as well. And you're going to get the same difference here as you would get here. So the last round of the differential characteristic in the first round does not cost you anything. You get things for free.
Promotion. So then you can do the analysis of what's the probability of this entire structure. To succeed well, it's a probability of this differential times the probability of this differential, this differential, this differential and the probability that the magic in the middle would work.
Of course you have to take into consideration that there are dependencies between these conditions. And the thing is that there are several earlier works, mostly by Dmitre, who actually did similar things for SB networks and S and also in Feistels, but one of the problems there was I had just shown you that there is dependence issue. And then you assume that there is dependence issue you exploit it as much as you can and then you say starting at this point everything is independent. Which is kind of tricky. You have to do it very carefully. Probably most of the time it works.
So I mean with Feistels you can use either gamma R equals to zero, meaning that the right-hand side here would be zero or if it happens to be that gamma R is equal to beta R is just swapping the order of the values. It also works well just repeat the previous example with flipping XC becomes XD and XD becomes XA.
Okay?
>>: [inaudible].
>> Orr Dunkelman: Oh, the sandwich. Yeah. Why do we call it the sandwich?
Thick slice of bread, thick slice of bread and here put anything in the middle which your religious authority allows you. Ham and cheese, I don't know, whatever you want to put there.
>>: Spam.
>> Orr Dunkelman: Huh?
>>: There's hardly any religious authorities allow spam.
>> Orr Dunkelman: Okay.

>>: Or health authorities either.
>> Orr Dunkelman: Well, at least this is not a same morphism attack. Sorry, this is Washington. It's allowed here, right? It's not like in California that same morphism attacks are not allowed. Homomorphism attacks are not -- sorry.
Okay.
>>: [inaudible].
>> Orr Dunkelman: Huh?
>>: [inaudible].
>> Orr Dunkelman: Okay. Good. Anyway, the thing is that KASUMI, which is the main point of this talk, that is a very nice three round related key differentials.
So nice it has probability one over four. And you can actually force it to be half if you treated them two plaintext bits. So you just flip one bit here, you flip one bit of the key, and this probability one over four you're going to get this. And we experimentally verified that this is indeed the case. Now, the good thing is that you can actually push everything four rounds forward. You cannot push it three rounds forward because of the fact that the order of the FL and the FO changes.
So you cannot use the same thing. But you can push it four rounds.
And then you find yourself with the following situation. 0001000 goes to the same thing. Going back. And as you can see in the middle we have a problem because we have three rounds here, three rounds here, and there is this noticing fourth round.
Luckily for us, this is the same difference. So there was a great rejoice in the count because now everything is [inaudible]. Okay. Some small technicals.
Probability first differential one over four, second differential one over four. There is a probability in the transition. The reason there is a probability in the transition we are using related-key differentials.
So various differences in the keys pop up in different various locations so we don't get it for free, we get it probably to do minus six. So the [inaudible] probability is to do minus 14 for seven rounds of KASUMI. Just to give you an indication, the previous sort of probability impurity in seven round KASUMI was two to the minus 45. So this is actually --
>>: [inaudible].
>> Orr Dunkelman: In real crypotosystem that was designed after the introduction of differential cryptanalysis a real cipher.
>>: [inaudible].
>> Orr Dunkelman: Or field. One of the most important ciphers in the history of cryptogram. That's why this is two to the minus six. If you want the exact details.

So we have color coding. I would like to express my apologies in front of -- on behalf of any one of you who happens to be color blind, I'm terribly sorry. You'll have to do with me telling you the names of the colors.
You have four values, XA, XB, XC, XD. If they all have the same color, that means they have the same value. Random value. We don't care as long as it's the same. And of course here you have XA equals 2XD and XD equals 2XC, but they are not exactly between themselves, and you can get the first round for free, the second round for free. And then in the third round you have XA equals to
XD, XB equals 2XC which is this case. And it happens to be the case that here
XA equals 2XD, XB equals 2XC and everything works fine until the point where you XOR the keys. And you ask for two different keys with two different values.
So we transform everything. And we might get screwed here but with probability
2 to the minus 6 either we get the same value in XA, XB and the same value in
XC and XD, or XA values 2XC or XB equals 2XD.
And this is actually the fact that it's 2 to the minus 6. Our prediction was 2 to the minus 7. And then I was coding it and counting how many things happened and suddenly I get twice as much as I expect. Okay.
Probably there is something in the analysis. We redo the analysis, 2 to the minus 7. Everything is fine. So there is probably a bug in my code. More probable. We go over the codes. Nathan actually looked at the code. We have no idea what's going on. We tried to chop rounds. We tried to move things around. It's still twice as much as we expect. Until the moment that you have this Eureka moment where you never run around naked in the streets of Tel
Aviv? Well, in any case we just found out it's 2 to the minus 6 because there are two options.
Implement, implement, implement. Anyway --
>>: [inaudible].
>> Orr Dunkelman: No, no, this blue square is not necessarily this blue square.
It's always inside -- we don't care.
>>: [inaudible].
>> Orr Dunkelman: These ones are just balance, meaning that if you take the X of all these four, you're going to get zero. Which is the property this we need. At the end you need to have balance in both sides. And this happens with probability to the minus 6. In any case.
So you take 2 to the 24 cyphertexts. We do it from the bottom up approach. You can do it, if you really insist, the other way around. You partially decrypt it. You ask the decryptions, sorry, the full decryption -- sorry. You xor alpha, you ask for the encryption, you collect the new ciphertext, there is a way to throw away most of the wrong quartets immediately. There is a new trick that we take a bit more extra data in order to identify the right quartets immediately. And you can almost

immediately identify your right quartets. And you find all the right quartets immediately and then you just analyze the last round, the eighth round. In theory you would try all possible 128 bit subkeys partially decrypt and see what works.
The thing is that there are 128 bit subkeys, so this would take two to the 128, so we do slightly different analysis by ordering everything and you can find 96-about its of the key in 2 to the 32 operations. And the remaining 32 bits we just do exhaustive search on 32 bits. It should be doable. Questions?
>>: [inaudible].
>> Orr Dunkelman: Actually it's 2 to the 32 because this is 2 to the 32 operations in one round. You don't of to do four encryptions. So it's 1.20 -- 1.125 times 2 to the 32. Please allow me to call this 2 to the 32 and if you have issues with this
1.125 factor I'm terribly sorry. I will buy you a beer afterwards.
Okay. So now we have a very high probability thing and let's do some experiments. Take to have to the 6 in random quartets. We use the variant with slightly higher probability to avoid several technical issues. So probability is 2 to the minus 13. We would expect eight right quartets. In each of these experiments we repeat it 10,000 times. And you can see that in theory we'd expect 34 of these experiments to have no right quartets and 32 we don't.
Which is good. I think -- I really like the seven and the eight examples because this looks like we cooked the numbers. [laughter] the code is running. I cannot send you the code because it's in France and exporting cryptographic codes from
France is a complete mess.
>>: [inaudible].
>> Orr Dunkelman: Huh?
>>: This is not cryptographic code, this --
>> Orr Dunkelman: Well, we used the official KASUMI implementation, so even though you can download it from here, from the server that sits -- that resides in
Finland, I'm not going to send the code outside. I'm terribly sorry. Please free to hack into the computers at DNS. It's hidden somewhere there. Once you do, there are several bugs in the system that you need to fix. But we'll discuss it later.
I really ran the experiment.
>>: [inaudible].
>> Orr Dunkelman: Huh?
>>: All the numbers in the experiment get 10,000.

>> Orr Dunkelman: Surprisingly enough, this is the case. I hope. And you can
-- it seems very close. You will have to trust me. I really ran the experiment.
Okay. Let's try the 8-round attack. And what we are going to do. I know the key.
I selected the key. So I'm going to decrypt the last round and check if the attack works. I mean, just to see that everything works when they add the eighth round and check all the dependencies issues and that sort of stuff. So you take two to the 24 starting ciphertexts and so in total 2 to the 26 data, probability 2 to the minus 14, we cannot enjoy the factor of two that we had before. And the probability of minus 14. I repeat the experiment. I would expect about four right quartets. And you can see that it's still close enough.
These are not looked, unlike the previous results. But it also looks very -- the previous were not cooked as well. The eight is very suspicious. Okay.
>>: [inaudible].
>> Orr Dunkelman: Yeah. Next time when I cook numbers I'll take it into consideration. Okay. Now, seriously, though, we have an attack. Everything works. Let's take one of these instances which we had seven right quartets and run analysis. Great. So I took them. I timed exhaustive key search on my machine. It took 26 minutes. I used the official code of KASUMI and afterwards you will hear comments like that you reimplemented KASUMI. How do you know it's the real KASUMI? I don't know. I write very bad code so it took the official code. It takes 26 minutes. Okay. So let's see how much time my code runs.
430 minutes.
Okay. That's a good first generation code. Let's improve it a little bit. Let's improve it even a bit more. And a bit extra hire me. I'm really good. Two to the
12th -- sorry, 212 minutes and at that point I said okay, okay. I did all the tricks that I know. I used the memory in different ways. I did everything by the book.
Something went wrong. And we looked inside. Actually we found out that we invoked exhaustive search part eight times. That means that I couldn't reach much below 200 anyway.
In all other attacks at that point I said okay, we know that exhaustive key search takes 26 minutes. I'm just going to count how many times I call exhaustive search and I just add the running time. There is no point actually running it.
In all other attacks we hit a minimum of two. At least you have to call the exhaustive key search at least twice.
Now, there is a reason the title of this slide is all I really need to know I learned in...
Apparently when you deal with differential attacks there is a small technicality.
You cannot distinguish between the key and the key X for the difference. It's technicality. Come and ask me afterwards why this is the case. But you cannot do that.

So of course you are always going to get two keys. But why did you get four, eight? This happens. Bad luck. I happen to pick the cans with seven write quartets that succeed in finding only 93 bits of the key. Bad luck.
So this time we run the attack 100 times, again throwing away the exhaustive key search, priority is not interesting. In 78 of these experiments we could actually find the key. The theory predicted 76 percent, so we are fine. In 46 of these, it would have taken up to four exhaustive key searches.
So it's about 120 minutes, 110 minutes. Which is quite practical. And in 12 more you need 8 exhaustive searches. The worst case I think was about 200 exhaustive searches in one out of -- I think that at this point you can say well, sorry, we failed. It just changes the succeed rate I think too important there.
Okay. So this is actually a practical attack. I hope that we all agree.
The thing is this is not a practical attack, this is practical complexity. You cannot attack A5/3 in real cipher -- in real deployment. There are two reasons for that.
The first reason is the fact that we need four related keys in the attack. I was hiding this fact that we use four related keys due to the fact that you take the key and you just duplicate it. You can get two out of these four keys. But the four keys cannot all of them together be allowed. They are not allowed in the GSM networks, in A5/3.
In A5/4 and UAE1, you can get the four keys. But you cannot attack GSM networks.
Another reason we cannot really attack is that we need adaptive chosen plaintext and ciphertext capabilities. F8 and F9, due to many reasons do not give you adaptive chosen plaintext and ciphertext capabilities. So this is only attack on the crypotosystem, which shows that the crypotosystem is not that great. But don't worry. There are more serious issues with the mobile phones than
KASUMI.
Okay. So some final thoughts. The actual implementation found a factor 2 difference between theory and practice. We know that in practice, practice wins within theory, the theory wins. So please whenever you have an attack which is close to complex, please implement, verify, implement, verify, implement repeat.
Actually it gave us also a factor of two in the analysis, the implementation. So as
I said, karma thing. Everything balances out at the end.
Now, it's worth to mention that there are seven possible sandwiches. You can shift everything a bit and then you can get the different subway, just put here some random sandwich joke.
In any case, it takes a bit, 75 percent extra data. And then you find the full 96 bit key. You solve the issue of two keys and everything is fine. Just decide if it's worth the effort.
Now, an interesting variant, and one of the changes that the people -- that the owners of KASUMI did was to change the key schedule. Now, assume for a

second they changed the key schedule slightly differently. Instead of using this word here and this word here, they would flip them in all locations, which will be consistent with their design criteria. Everything would be fine. So if you do the same, if you do this, the probability of the transition drops to zero. And we actually verified it experimentally. This is kind of stupid to experimentally verify something that never happens. But we actually repeated the experiment and all experiments failed. Okay.
If you really want a reason, I can show it to you. It's here in the color diagram. If you don't really want a reason, it's something with the S boxes. The S boxes have a very flat difference distribution table, meaning that there are no four inputs with the same input difference, the same output difference. And this is required in the previous attacks we use these facts.
We use this fact for our advantage. And here we cannot use this fact to our advantage because at some point you are going to get four different values entering into the S boxes, and you are not going to get the [inaudible] of all of them will not be zero at the end. Game over. Okay. So if you really want answer -- the technical data, why is it -- I mean, it's just a matter of the actual differences that's going.
So were they smart moving from MISTY to KASUMI? First of all, the changes that they did was actually moving the FL, the linear functions from the data path to the round functions, the MISTY to the FL functions are the data paths. It sometimes offer more protection, it sometimes offers less protection. So you can build variants that make it stronger or weaker.
They removed one key addition. And actually this adds to the security. I think this is one of the worst conclusions that you can think of in cryptoanalytic attack.
Remove the XOR with the key. It will make your cipher more secure. In some key schedules. I mean, you could fix the previous problem if the last XOR would have been there. .
The black art of cryptanalysis.
>>: [inaudible].
>> Orr Dunkelman: They added rotations to the linear function, the actual linear funding -- the FL in MISTY does not have rotations to the left. It doesn't affect us.
It might help or might prevent other attacks. They have one small layer of S boxes in FI. Without this, our attack would be 2 to the 6 time faster. On the other hand, the previous failing argument would not exist. So depending what you are trying to achieve, they use different locations for the sub-- if for the subkeys you know you can rotate the place, put things -- sometimes it helps, sometimes it doesn't.
They change the S boxes. Now, we didn't really use properties of the S box besides in the counter example where you need something to not happen. But it wouldn't have worked in the previous S box as well. And they changed the key schedule, which made everything linear which helped us a lot.

But, you know, I can reconstruct the key schedule which is more secure or less secure. So all in all, this is something which is okay.
Dirty details. 2 to the 26 adaptive chosen plaintext and ciphertext. As I said, you cannot achieve them in practice in the fields machine, but it's actually an interesting -- it's small amount. 2 to the 30 bytes of memory. One gigabyte of memory. That's it. You just need to store all the new ciphertext and you immediately through all the interesting parts. Time complexity, 2 --
>>: Who made the observation that you can use the memory in your cell phone
[inaudible].
>> Orr Dunkelman: Oh, yeah. You can use -- I mean you put a virus on the machine and instead of getting the key directly from the SIM card, which you can do by the way, the phone can access the SIM card and ask the keys directly.
I told you that cryptoanalytic attacks are not the most rewarding thing in fun. But in theory, let's assume that they do not allow you that, but they allow the phone to ask for encryption of stuff. You can actually do that. Time complexity 2 to the
32, 2 to the 33. I'm not going to haggle with you about a factor of 2, okay? Just start a cloud computer and then I mean start two of these.
And actually it's fully implemented. Thank you.
[applause].
>>: [inaudible].
>> Orr Dunkelman: Sorry?
>>: [inaudible].
>> Orr Dunkelman: What was your question before?
>>: I ask what you did wrong in the transition.
>> Orr Dunkelman: Oh.
>>: As far as your implementation goes, is that really the real reason you don't want to share is simply because you used KASUMI and as a follow-up, couldn't you just remove that and say at KASUMI call here and then go ahead and just
[inaudible].
>> Orr Dunkelman: There is always a problem when you try to distribute cryptoanalytic code. I mean, you never know who is going to try and use it for really bad things.
Now, my assumption is that the really, really bad people --

>>: You probably --
>> Orr Dunkelman: Can probably read the paper and implement on their own.
But I see no reason to help them. I mean -- and besides it would expose the way
I write code which would be very embarrassing. I mean I would immediately get a job offer from three software companies but usually cryptanalytic code is delicate. It's something --
>>: [inaudible].
>> Orr Dunkelman: This was a period -- this is a period in this crypto.
>>: In the [inaudible].
>> Orr Dunkelman: The real crypto.
>>: [inaudible].
>> Orr Dunkelman: The paper is also the full paper with all the dirty details about the impossible variant is only a print --
>>: Okay. Great. Thanks.
>> Orr Dunkelman: If anyone wants a copy or snippets of the code like they include STDIO, I'm willing to supply these. Yeah?
>>: I used to think that related to key are science fiction then of course came
WEP and I woke up in a hurry. But was there always thought in practice by running every key stroke encryption was a key of zero or am I too naive?
>> Orr Dunkelman: If you are using an algorithm like T, then it won't help, because T has issues related key issues which are so large or like DS, you know, there are complementation properties issued. So you might actually fall in one of these. So you have to be very careful.
Or an idea for example the key zero is in so many Wiki classes. So the key zero is not the perfect selection. Pick something else. But I think that I've heard the suggestion. Just take the key, throw it through MD5. MD5 is not great hash function, we all agree, but it should be sufficiently good against this sort of thing.
Yeah, it should work. But for a simpler -- important a cheaper cost you can have better key schedules instead of starting MD5 and initialization finalization and, you know, relying on some other permutation.
>>: For exactly the same reason if we had [inaudible] 2 to the 22 the time single
[inaudible] crypotosystem we will put the title that's going to take all this crypotosystem. Then we were very careful to say in practical time it take on this crypotosystem because it's fair. I wouldn't call this a bit practical due to the difficulty of mounting relate key attacks in most [inaudible].

>>: Could you say that [inaudible] you said that the true [inaudible] particular related key [inaudible].
>> Orr Dunkelman: Okay. So the proof assumes that the adversary has access to two keys. So the fact that we were using four doesn't nullify the proof.
>>: I see.
>> Orr Dunkelman: Yet. I mean, I guess that asking [inaudible] about it when we had the first attack from 2005 is -- he looked at it and he said listen, it's four keys, so everything is fine. Again it's sort of -- you know, there is this concept of confidence and trust. And you need this warm fuzzy feeling inside of you when you look at the crypto system. And the fact that, you know, you add two more keys to the adversary and everything collapses it's kind of weak. I mean, at some point someone would say okay, take the full round differential characteristic that you had, add the two round differential with no related keys. I mean, if you really want to try and improve this attack, probably there are several ways to prove it, to make it work against KASUMI with two related keys.
It's not going to be amazing, but it's going to be -- to break the security. I think there is a saying that says that everything which is prove my secure is probably not. And in any case, KASUMI's not a problem. I mean, even if you throw way
KASUMI you put AES you know, or don't put AES. Put something. Whatever you want to put. The problem is in the interface because you can ask the SIM card, can you please give me this secret information. I didn't mention it. Each
SIM card has about 10 preshared secrets with your operator of one 28 bits, the best case you can think of. And your mobile phone is allowed to ask it from the
SIM card.
>>: Are you sure about that?
>> Orr Dunkelman: This is what implementation people told me. Even though it's.
>>: [inaudible] and tried to remove those keys, and I had -- I mean, I'm no expert but I have tried to do it, and it dust seem [inaudible] specifically try not to let you do that.
>> Orr Dunkelman: From what I understood you can just take the SIM card, put it in your own and just ask the SIM cards. Maybe the phone didn't ask it, A. B, there are so many specs, I said it at the beginning of the talk, 2, 2.5, 2.9, .95, point -- God knows what's running around there. And most attacks at the end, if you have access to the mobile phone, it's very simple to read the data from the
SIM card anyway. There are people who actually do that.
>>: I thought that was [inaudible].
[brief talking over].

>>: I thought the original plan like the original COMP128 attack was really to roof
-- you queried the SIM card so many times that you derive that preshared gain.
And I don't -- and I think once they fixed that there's no, at least known to my knowledge, way to actually get that preshared key out of it. Otherwise you could clone SIM cards really easy. And that's what they wanted --
>> Orr Dunkelman: The one person who actually does it almost on a daily basis.
>>: But he does it by [inaudible].
>>: [inaudible].
>>: I think that the API [inaudible] says the SIM card does not allow you to ask --
>>: So if you can go in like shave off some top and take really good photographs and then, yes, okay, then.
>> Orr Dunkelman: It does it in a way that give you back the SIM card and you don't know that it was [inaudible] so it might be breaking the protocols through some other whole loophole or some -- but there is a way to do it.
I know of a guy doing that.
>>: He actually takes that out of the --
>> Orr Dunkelman: When he takes it from the -- he has access to the phone.
>>: [inaudible].
>> Orr Dunkelman: In case, by the way, just a comment. If you ever get arrested in France and you give them your mobile phone and it returns without battery in the sense that the battery is dead, that means that someone there read your SIM card.
>>: [inaudible].
>>: Can't they recharge the battery at least.
>> Orr Dunkelman: I have no idea why they do that, but.
>>: They are French.
>> Orr Dunkelman: Jacques Cousteau does not charge other people's phones.
>>: That's a green thing.
>>: That's a good excuse. You should be in PR.
>>: [inaudible].

>>: I have a few questions [inaudible] so what is the percent among all
[inaudible] non practical [inaudible] would survive if you double the number of rounds; in other words [inaudible] fact of two [inaudible].
>> Orr Dunkelman: There is a class of attacks --
>>: [inaudible].
>> Orr Dunkelman: There is a class of attacks called the slide attacks. Which is independent of number of rounds. Now, some statistical attacks are so strong in some ciphers that doubling the number of surrounds won't help you. T has related key issues independent of the number of rounds. Ghost has related key issues independent of number of rounds. Frank, you -- best has implementation property even if you double the number of rounds. Even triple this as complementation property for that matter.
So [inaudible].
>>: Well, now one thing is why that is always -- I understand with practice people want, you know, [inaudible] hash function [inaudible] they want the [inaudible] as close as possible to the best attack but [inaudible] when they see some of those things, that is some of the remarkable stuff that you guys do, and then very often people say okay you can do like 7 but not 8 round but 9 is completely hopeless, it's like how on Earth wouldn't those guys just say okay [inaudible] practice double the number of rounds and, you know, just [inaudible] so that [inaudible].
>>: That was tried in the AES competition [inaudible] had 32 rounds and they were running at less than half the speed of the other ones and they didn't win.
>>: I know and [inaudible] exactly -- I'm just curious, you know, for future
[inaudible] why don't they just run 8 as the minimal number of surrounds you know or whatever has to be at least a factor of 2, let's make it 3 to make sure that that is in existing attacks and then -- I mean, I know that a [inaudible] but I mean
[inaudible] is it practical attack [inaudible].
>>: You have an argument with the embedded device manufacturers then go see who wins. [laughter].
>> Orr Dunkelman: I would like to take this opportunity to do some blatant PR for my next talk. I think it's on Thursday. If I'm not mistaken I'm going to talk about the SHA-3 competition. We had this wonderful discussion last week in Santa
Barbara about SHA-3. And I think the people who were there start laughing.
You know, security costs a lot. Josh can tell you here for example that people are still using SHA-1 because SHA-2 is way too expensive. If you look at the performance figures, we are talking about doubling the performance cost.
>>: Triple.
>> Orr Dunkelman: Huh?

>>: [inaudible].
>> Orr Dunkelman: Okay.
>>: You want to hear a sillier reason? I was trying to tell some people they shouldn't use MD5 [inaudible] they said oh, well we don't know what good SHA-2
[inaudible] JavaScript so we couldn't possibility [inaudible].
>> Orr Dunkelman: There are good SHA JavaScript implementations. But in any case, people don't want to pay for security. Now, what you pay is what you get.
>>: The second thing, I'm not sure if it's practical, but at least [inaudible] is it possible I know that some [inaudible] like 128 and 256 kind of variants but I'm just wondering how practical is, you know, the required at least some [inaudible] you know, a hash function or block cipher. Because sometimes there are a lot of choices that are completely [inaudible] you can say okay, you know, this is only like for whatever, 16 round or whatever is the right number and -- I'm just curious how expensive would be to force people to [inaudible] at least to envision this
[inaudible].
>>: So this was discussed in the [inaudible] competition quite a bit to have number of rounds which have negotiation in the SL negotiation. It opens you up to attacks where I try and cheat the negotiation algorithm, make you believe you use 24 round and him believe he used 26 rounds, and then I get a 2 round attack because I'm going to make you encrypt and him decrypt and get -- really choosing them [inaudible] is so complicated, farming out to people who know even less is probably not a bad idea.
>>: Well, I'm not sure --
>>: Look at the telephony situation. If you had the A5/0, A5/1, A5/2, et cetera, just [inaudible] attack in which you convince the other parties use the weak version then you [inaudible].
>>: Yeah. I'm not saying [inaudible] each one to use a strong one or a weak one, but at least also sometimes it's very hard when people put encrypt and someone says [inaudible] fast computer. [inaudible] think just a little bit was
[inaudible] for the attacks. At least you know, some simple, just the basics in the number of rounds. So [inaudible] a little bit more believable, and also people would be more or less impressed by a particular -- by just seeing some
[inaudible] but I'm not sure.
>>: I'm in favor of your suggestion to have the large [inaudible] but time to apply it to DES when DES was designed I think that people didn't know how to attack 6 rounds of DES. Actually there were papers later on showing how 6 rounds of
DES could be broken. So assuming that 6 was the number available they would have suggested 12 rounds [inaudible] to make [inaudible].
>>: [inaudible] I mean I think it's [inaudible].

>>: [inaudible] factor of two might be not sufficient in some cases. Certainly it's a good start.
>> Orr Dunkelman: Another issue is the fact that besides issues where you try to negotiate things, the people who do implementations, if you look at SSL, you can say, listen, SSL was not designed in crypto-agility. I think this was the name they were trying to push at some point. That you would be able to change. Why are we stuck with MD5 when, you know, the protocol should allow you to change the hash function to something else in the future, but IETF works in such a way that
SSL you have to -- the handshake tells you I'm going to use MD5 with AES, with and when AES came into -- into existence and when it was selected as a standard they asked to double all the number of parameters from stop working with triple S, start working with AES.
>>: That's an argument that we lost.
>> Orr Dunkelman: But that's the problem here. People who do implementations have -- are more likely to screw up these things than they are to screw up here is a black box that does AES. Use it. Period. Here are the test vectors. If you do not confirm to these test vectors, you're dead. The fact is that we know how to build block ciphers better than we know how to build protocols.
Still this is the case.
So why to push the problems to where we don't know how to solve the problem rather than, you know, let's keep it in block ciphers, double the number of rounds.
I agree, but the problem is if you try to parameterize things you generate a problem to the protocol people. You know, key exchange is still not solved. So you want to throw in some -- okay. We now agree on the number of rounds.
Yeah?
>>: I'd also point out that in practice of all the vigil of fraud going on, I don't remember hearing of a single one which actual used cryptanalysis, right? It's never the weak point. Even this stuff. Why would you bother doing this if you can steal your [inaudible] so we're actually doing a pretty good job as cryptographers.
>> Orr Dunkelman: WEP. WEP. WEP. WEP, WEP, and WEP. One single attack that actually cryptanalysis matters in real life. WEP.
>>: Someone that launched attacks against WEP were really involved with protocol and things that weren't really WEP --
>> Orr Dunkelman: Yeah, but I mean --
>>: [inaudible].
>>: [inaudible] back in the cipher, right?
>> Orr Dunkelman: It's not --

[brief talking over].
>> Orr Dunkelman: [inaudible] the fact that the cipher has issues. If you put this aside, the problem is the fact that they put the IV here and not there, and actually there is a paper by [inaudible] '05 that if you put the IV here and not there or there and not here, where everybody believe it was okay, you can still attack it.
So we still have issues with the fact that it's RC4 in this specific mode with 24 bit of JAFIV and that and that many bits of key.
But there is one attack where the crypto actually is the source of the problems.
Now, of course if you select weak passwords or you know the protocol is still not using R C4 correctly, we're screwed. But I mean --
>>: [inaudible] implementation --
>>: But even if people did this attack, but I haven't really heard of people like robbing the blind or stealing money by attacking the WEP.
>> Orr Dunkelman: Actually I think that the TJ Maxx credit card fraud --
>>: Yes.
>>: They actually lost a billion dollars.
>>: Yes. Yes.
>> Orr Dunkelman: So.
>>: But I think you're right [inaudible] attacks --
>> Orr Dunkelman: We have an example. [laughter].
>> Orr Dunkelman: But it's worth a lot. 45 million credit card numbers, you know, I'm willing to say this is a good example. I don't know if it was 40 or 45.
>>: [inaudible] 20 years [inaudible].
>>: He stole a billion dollars --
>>: No, it cost TJ Maxx to refund banks and they were changing tens of millions
--
>>: [inaudible] not one store.
>>: The one store was much smaller but it cost TJ Maxx [inaudible].
>>: [inaudible].
>>: Look for TJ Maxx, Tech, Gonzalez and credit card [inaudible].

>>: Credit card --
>>: There was a guy who was sitting next to [inaudible] TJ Maxx in
Massachusetts, in Boston, and the -- they were moving all the credit card information by WiFi and using the protection available in the WEP and he
[inaudible] using hidden [inaudible] put he was implementing [inaudible] and using it, and that's how he got [inaudible].
>>: [inaudible] transmitting the credit card [inaudible].
>>: [inaudible].
>>: [inaudible] policy question. You're saying TJ Maxx had to pay for all of it because they [inaudible] something on the shelf.
>>: Visa has very strict policies that if you deal with credit card numbers you have to follow these guidelines and I assume TJ Maxx wasn't following the guidelines and [inaudible].
>> Orr Dunkelman: [inaudible] would have told them, listen, we are not going to deal with you anymore, right? Actually go to TJ Maxx store and say sorry, sir, we don't accept Visa, only Mastercard. And also Mastercard was affected and
American express. And I think -- so nobody would work with them.
Please bring your cash with you.
>>: And they don't like cash because the staff makes it disappear.
>> Orr Dunkelman: Yeah. Okay. Thank you.
[applause]