 Thank you very much. I'm Marku. This work was actually supported by a very security, who were the owners of... I'm going to... That company is no longer in my background. Sometime last August, so I'm here. This one doesn't work. I'm just supported by the current intellectual property owners of Hummingbird. I don't even know who those people are. Anyway, some gentleman takes us to the concept of my trip. Did I just switch this one? Hummingbird 2, which was, which is a successor to Hummingbird 1, came out in two years ago. It's a library not located encryption organ for, which was actually designed to work together with a specific arbitration protocol. For example, in ISO standardization forms, these two have been proposed together. So it has been designed for very specific frames. So it should really be looked at in that context. For example, in this protocol, it's only found in encryption mode. Because the protocol is used for authentication, encryption is not even needed. But anyway, we actually evaluated it in the context of a general library of encryption organ, so you don't really have to care about that. But anyway, it has a 128-bit secret key, and obviously that's also the security claim, and a 64-bit IV. And, you know, there was, in the previous talk, the non-previous issue was mentioned, and because of the way this particular cypher is being used, it's unavoidable because the IV actually comes from the interoperating part, so you can avoid the other part of it giving you the same IV twice. So it's supposed to be actually resistant to repeated IV attacks. This is actually a repeated IV attack. So it's not announced. Yeah, so I was involved actually in the design of this cypher. So we were only allowed to do minimal changes. So this was partially because of intellectual property issues. Hummingbird 1 was patented, so the same patents had to apply to Hummingbird 2. We were, our hands were a little bit tight there, but anyway, because Hummingbird 1 was quite seriously broken, so it had a 256-bit secret key, which was obviously too large, and you could cut down that into the 2-to-64-bit single key attack, so it was quite devastating. And I'm not aware of any other attacks against Full Hummingbird 2, so there's been some e-print things, but those have been mostly actually bit from them. So there was one claiming a 2-to-36 attack, so I emailed the authors and said that surely enough you implemented this and it must work like within a minute because it's 2-to-36, and there was an email back one week later saying no, we haven't implemented it and they just went through the papers. So there's actually been quite a few e-prints like that and none of these attacks are valid, so there you go. So the architecture is based on 16-bit databats, so the target was really ultra-light weight microcontrollers and hardware implementation, and more specifically, Texas Instruments MSP 430 family which has 16-bit bears and 16 in general service registers, so at least designed fairly well with that part in order to ultra-light weight MCU. The cipher has almost no key schedule, so we split the key into eight 16-bit bears, so I'm using this notation later on in the talk. And there's only one non-linear component, it's called WD16. This was named by our marketing department after our mascot, Pete Diffing, so supposedly he designed this on a cocktail napkin somewhere. Anyway, they like to play it, and it's actually designed by Pete Diffing and by Pete Diffing, so we have WD16, which takes in 64 bits, and these 64 bits are either the upper map or the later half of the one-train with key always in this talk. WD16 can be viewed as a mini block cipher with a 16-bit plaintext coming in and a bear coming out. So we made a very simple observation. This is actually something which was inspired by one of the bit-throne e-brings by Kaizhran, Liimding and Ji Yuan from China, and they had a valid, related key observation on WD16, but they apparently failed to turn that into an actual working atom, so that's the thing. So here we have the structure of WD16, so there's four arms, there's four by four S-boxes here, each one of these are the same, but there's four different S-boxes here, and there's a linear mixing phase here, and it's keyed by 64 bits, so there's four subkeys going in here. It's a fairly simple thing. So zooming up to the first round, we can see exactly how it happens, how it works, and if you have a simple related key here, like inverting the high-most level here, only one S-box is obviously activated, then we have linear mixing after that, and quite obviously if you have a certain probability, we can cancel it out if you have a related key. Because these are four by four S-boxes, you always have at least, you know, differentials, probability one over four. Actually if it's a good S-box, like these are, all of the differentials are one over four. Right, so we observe here that we have 64 bit related keys for these WD-16 instances that actually produce the same output for these two related keys with probability one over four, because the subkeys are only used once here. So that's one word, that's one word, that's one word. And one should also know that if this difference is actually coming from up here, from plaintext side, then we also have two plaintexts which actually produce the same output under related key with a high probability, so we can have basically coalitions in WD-16 easily as well, with high probability. So I'm using both of these trivial probabilities in the attic, which is actually quite simple. Oh yeah, I should note also that actually they haven't burned one attic, where I can say any WD-16 dive function, so that was totally relevant to the attic. Typically I claim that it's two to six to four, because that's the general case, just based on the structure of Hummingbird one, but if you look more deeply into the actual contents of WD-16, it would be easily pushed down to like two to 32 very realistic values against Hummingbird one. Now we go to the structure, that was WD-16, now we look at the data pass which are 16 bits. So first we have a sort of a key setup phase, so we have four arms like this, where we start with the IV value here twice, and we run some additions and rotations to sort of mix it up into a 1.28, which that's the IV setup phase. There's a counter here, and really the keys I use here twice. So here we use subkeys from one to four, one to four again, five to eight, and five to eight again. Because the key schedule is so silly, we actually note that there are related keys that we do with one over 65,000, actually produce the same IV value as the four arms, because if we have a relative key position here, these subkeys are the same, and here again that's where it happens. The number of related keys or the related key family is simply, that is the highest probability related key family. There are others, I mean lower probability, but still perfectly realistic. So I'm just focusing on the easiest related key families. So because that's one thing that Ivan thoroughly put into the paper, is that because these related key families are so large, you can actually hit them by chance in an RFID setting. Especially if the RFID has something like a master key, or if the private keys are derived from serial numbers which happen in keylog, if there's issues of that nature that the secret keys aren't entirely dependent, that they aren't derived from something, you have a fair chance of actually hitting related keys, if you have a big file of RFID tokens, it's actually finding a pair which have this relation by chance, and in a related key you can obviously then derive the master key by using that pair, so it's fairly realistic. And one should also think about the sort of vegan versions of pieces, because then it gets totally silly. They're easily grateful. And those do exist. Now the encryption part. So having a pair isn't like a stream cypher or exactly like a clock cypher. And because of the requirement of even for the very first bird to be resistant against an axe, unlike in like a duplex mode or similar modes, you run a presentation on each plane expert to produce each cypher expert. We cannot just sort that with the state and then mix up the state or something like that. So we have a, that's the encryption pipeline and then there's mixing with the staples here. These are additions. And there's also some variable keying. These last four staples are actually used to key the middle row rounds here. So that would be total interior. Like in Hammond Brake 1. But anyway, because these key birds are sore and the related key family is based on sore, that doesn't really matter. If we have K1 to K4, again here, that's 5 to 8, we don't have to worry about that. We only have this one or four, probably we haven't twice, but it's the same cypher test. We observed that there's a very high probability, 1 over 16, that if the state matches, if we run the IV setup, find an IV value which produces a collision in the state after IV setup, then we have a very high probability that these two related keys will actually produce matching cypher tests. Obviously, it's quite easy to test because we allowed this repeated non-seract type of model. So, coming to the actual key recovery. I just thought it's a very big one key relation that I'm using here. So we have two black box, let's say, RFID tokens, and we are issuing various there. And they are related by this. And obviously the task is to figure out key. So these very basic observations, you can actually develop all kinds of attacks. This is the one I implemented and run successfully. So that's the diagram I'm describing. So the first step in the attack is to find an IV value. We only need one IV value which produces a state collision after the initial in phase for these two keys. And we've already seen that it's very easy to do. We have two to sixty in effort and we have such an IV value. And it's easy to detect because we have matching cypher tests for some of them and next one is two keys. Now, we call the encryption routine here. Two months. They say the first attack, actually the very first period of the internal state. And that's done by analyzing the interplay of this addition, the very first addition of the register word one to the plain text word which is, by the way, the diagrams and the equations I'm using the same variable that's temperature variable zero. And then it goes into WD16 where we have absorbed between the key words and the plain text word, WD16. So it's all based on interplay because we can choose plain text P1 here. We don't know this one but we know what happens in here. So this was trying to create a collision here. We use a pair of plain text words which we can choose for the two black boxes. And with certain probability we get a collision after the very first WD16 invocation. And that tells us about the state of the first register word here. It's just based on the particular characteristics of the S-prox that's in there. So there's some technicalities here but it really has to do with garbage and the way the S-prox have been selected. You can build a table like this for any S-prox. Now, as you have actually you have the value of R1 in like two consecutive plain exposition. So you can see that it only changes by this addition for example here. So by subtracting those from each other we obtain an internal quantity here. So after that you have one of the internal state variables. Just because it's based on these additions and things you can actually work out with fairly basic algebra just filling the equations around simplifying them. You can work out much of the rest of the internal state. So that's all in I believe in section 3.3. So because this is a because we can repeat the same value you can just rewind back the side for new stuff again try different things actually build full codebooks full 2-to-16 codebooks for certain position and analyze those for more information. But anyway so after that exercise we have two internal quantities D1 and D0 for example position. So that's D1 D0 and D1 we know these values and we know that only 64 bits goes in here. So that allows us to basically break the cyber in half. So because we have these values and we are full forcing WD16 instances we don't have to worry about the other half of the secret key. So that already gives us a 2-to-64 attack. So first we attack this half. Obviously then the second half is a matter of root force. The whole complexity of attack is 2-to-64. Then one can see that actually having equations like that allows this to be split in half because each one of these keywords is only used once in the WD16. So you can do a time memory trade-off for this space. So actually attacking the first half of the secret key can be front down to something like 2-to-36. But if you do that I haven't figured out a way of doing that to the second half. So that root force phase of the second half of the key dominates and the overall complexity is still 2-to-36. But again that's the case if we have this particular relation. So if the relation can be in any one of these positions this difference is cancelled by this. So we can shift this for example one position one position right and it will still be a perfectly valid relation. And I do actually believe I'm fully aware to die by there's probably a way of doing a time memory trade-off on both halves. The other related key model the security of the whole thing closed out in like 2-to-32. That's very much true if we are in a crazy attack model where we have multiple relations. I've seen that being proposed. If we have like 32 related pairs somehow then you can definitely get the common secret 2-to-32 effort. So in the paper in the appendix I was asked to sort of propose an alternative to WD16 which is obviously the weak link here. I wasn't allowed to touch any other part of decipher which is pretty bad because I know that it has features that I don't really support myself. In the appendix of the paper there's a version called or I'm a bit too new they are replaced with key functions. We love these key functions nowadays because well for example S-boxes are sometimes vulnerable to cache-side channel attacks and things like that which don't really have a lot of key functions. These are something that we engage and are rotation independent. So it's just based on these two involutions and a bunch of constants. The hardware implementation is actually smaller than the one we've been to. The software implementation I wrote for MSP430 isn't that impressive but can you do it? MSP430 only has one big rotation right or left and here I'm rotating like a crazy amount so that's one of the reasons and that's what they do in the most order of the game. So you are welcome to try it out. I know that there might be some attacks and even related key this isn't fully resistant to related key attacks because I couldn't change the key schedule. So there you go. Just a little challenge. Anyway, so thank you. I like regular players. They just come along and live it. Thank you. Do you have a question or comment? So I have a question. So have you tried to apply other related key type of attack? For example related key boomerang attack. So related key boomerang or related key boomerang? Not necessary because this was sort of trivial. I like single things. So any other questions or comments? Okay, let's thanks again.