before we get started I just want a quick show of hands. So how many of you out there? Yeah there we go. Quick show of hands. So how many of you out there have done any kind of ethical or you know wink wink unethical hacking of financial applications. Any kind of all. Okay good. So yeah I've been focused on these things for like 13 years and I've seen some really crazy stuff. So now out of you guys who have done that how many of you have thought that the code was so beautiful so flawless that it didn't need even the slightest bit of human intervention you know once it rolled out of the desk right everyone right yeah I'm sure. So now imagine for a moment that that financial code couldn't be changed. You know once you put it out there it's just it's out there you know. So if it has any huge gaping flaws or anything that's the way it's going to stay for eternity. So that's sort of what goes on in the world of smart contracts okay. There's no updates, there's no patches, there's no revisions. There's ways to point to other programs but once you put it on the blockchain by its nature the blockchain is this immutable thing right. So if this code is expected to move money around forever on its own it probably needs a little more attention than the usual financial apps you might have looked at in the past. So that's why this is an important field. And we're sort of getting it on the ground floor still here. Think about if you had gone to a web app hacking talk around the year 2000 you know that's the idea here this is very new to a lot of folks. So I'm going to try and you know ease everyone into it a bit.  So no I'm not just going to explain how Bitcoin works that's silly. But I assume you guys know that. But I'm just going to explain some of the quick differences and what makes Ethereum different, better and a lot more usable in terms of things like smart contracts. So everyone's aware of Bitcoin yeah we know that. So Satoshi met his goals right he wanted to have the whole distributed ledger to avoid double spend you know have had the computational proof of work make this thing actually be of some value. And some altruistic goals because half the world doesn't have a bank or access to a bank so now thanks to Bitcoin they do. But with Ethereum we've got something different going on you know it takes the idea a little further creates this this idea of a Turing complete system the EVM the theorem of virtual machine that runs over the entire globe this one big mega computer that you can access and do things with. So it can save state it can detect changes to info it can remember them. It can intelligent handle interactions between users control flow programming so it could run smart contracts which is why we're talking about it. You know there are some companies building smart contract like features over the Bitcoin network but it's not quite the same thing. So what's a smart contract you know real simply so it's a program right it consists of business logic it runs on the blockchain it's semi-autonomous you know you can think of it as this like thing that just runs on its own which sometimes doesn't really bring comfort to anyone. So it can move value it can enforce agreements it can remove repetitive labor which everyone's all for but again it cannot be patched I can't stress this enough so it is important to really take a look at this code before you put it live. And reality you're limited only by creativity you know you can make escrow systems that hold money in place when it checks for terms you can create new tokens people think about tokens is like just extra coins but you've been using tokens all your lives I mean if you have frequent flyer miles for example that's kind of like a token like a limited set usage so smart contracts let you create ones that have purpose like that. It can handle real estate records you know if a country has an unstable government a smart contract approve you own something enforcing it's another matter but it could at least prove it digitally. It could do things like paid people when work is done trust funds wills you can even imagine something like Airbnb or Uber without the company behind it you know you can have these smart contracts negotiating for people so no one takes a cut when you take a drive or you stay in someone's room. So it's kind of a neat idea. So why should we look at smart contract security well I could literally think of a billion reasons. If everyone remembers the Dow which was a little over a year ago basically it was a decentralized autonomous operation and organization it was designed to operate like a venture capital fund letting you move money in and out. A flaw was found in May 2016 and no one really did anything about it and June 17 a hacker used a recursive flaw which we're going to look at in detail to make splits inside of splits and keep siphoning money out in a race condition without checking the balance. So 3.6 million ether was stolen back at the time they were reporting it accurately that it was you know a decent amount of money but if you look at how ether has gone as high as 400 or three something at times you know it's pretty much if it happened today it would be close to a billion dollar hack. So that would definitely make even bigger news than it did a year ago. Smart contract security is not going away it's not a problem that's you know last summer. It's something that's going to very much affect the future. And what's funny is I'll show you how you can prevent similar theft like that with just switching two lines of code as we'll get to. So more recently we had another smart contract attack. So 30 million reasons are good too. So basically parody was hit and there was a multi-sig wallet that allowed people to swipe 32 million dollars from a few ICOs. It's another ridiculously simple flaw that we're going to look at in this talk. But the idea is there you know people put so much money into these things and they have them be responsible for so many critical assets that to code them poorly is just not acceptable in this day and age. So a quick caveat there's no zero days here you know you can't always easily identify where the first time something was discovered but we're going to be talking about like I said imagine you've gone to web app hacking talk like around the year 2000. I'm going to try and introduce as much as I can in this time about what you should be looking for. There's no customer code that's going to be shared. I haven't shared customer code you know accidentally 13 years I'm not starting today. So you're not going to see anything from like real engagements. I'm going to use like sanitized examples and things like that. But this is about generating methodology you know I want you guys to be able to go out there and try and get involved in this especially if you spend a little time learning solidity which we'll get to in a second. And no I don't think smart contracts are that smart. I don't think they're going to like take over the world or anything so you know there's always that fear like I'm sure it must have come up in the talk I just missed. Yeah they're smart but not really that smart so no mega fears here. Okay so solidity. This is the programming language. Ominous Ethereum like looking symbol there for solidity. So it's the one that won out okay. You don't need to program solidity to do smart contracts but this is the one that everyone settled on. It beat out Serpent which is a little bit like Python, Lisp like language. It's high level human readable. It's kind of pretty in its own way I guess. It has some syntax similarities to JavaScript and C so if you have any of that in your background you know maybe you'll take the solidity quite well. And when you write this code it compiles to EVM bytecode. So it's statically typed. It supports libraries, inheritance, complex, user-defined types. It's pretty fancy. So obviously I can't teach you how to code in solidity in this 45 minute talk. That would be kind of crazy. So we're going to focus on the general types of vulnerabilities you should be looking for and maybe you can re-watch this video if you don't know solidity after you learn it. That's possibility too. So it's in high demand right now. I think it's worth taking the time to learn. There's a book coming out next week Ethereum programming. It actually looks pretty good to me so I think some folks might find it useful. If you learn solidity you'll be like the 10th person to do so. So congratulations to you. So it'll be really good too. Yeah we definitely need more. So ethical hacking of solidity is it's usually part of the dev process. Think of it as like a typical code review. So you know Sol files, the .sol files of solidity, they get compiled and they run on test block chains, then on private or public ones depending. So the customer or other environment could differ greatly so you're going to have to definitely talk to the devs about what's going on if you're working with this. So Matt Swish yesterday, I don't know if he's here but he gave great talk on his tool, Porosity. And that's what's kind of interesting because it lets you pull from the blockchain and get back solidity code. That's not what we're going to be looking at here. Here we're going to be having the solidity files handed to us up front just like you would have any other code review. So that's the sort of approach we're taking here. So the first step is definitely look at the solidity files before they go down that process. A good way to do that is to have an IDE. There's a lot of options available. My favorite's Atom. You can actually get a couple of plugins for that. And using it you can actually have highlighting and it can even test compiling which is pretty cool using EtherAtom. Real Mix ID is kind of neat. It's browser based and lets you try and compile code and see if it errors out. So that's useful too. Okay. And yeah, Emacs and Vim have plugins too. I don't want to start like a religious war but they do. Alright. So while you're still learning solidity, you might find it useful to run a parser like SolGraph. It's not a bad way to look at code even when you know solidity too. So it takes the Sol file and it outputs a dot graph that actually lets you visualize the function, the flow. So it sort of like walks you through how the code works just so you can get that big picture view before you even get started looking for the little nitpicky things. So there's another one called Solidity Parser coming out that looks promising too. So these kinds of things are just age, visual age because sometimes code just becomes, you know, like, mind numbing after all, right? So a really awesome tool that came out a while ago was Iante and it got both better and like sort of worse. I'll explain that. So it's a symbolic execution tool. It's designed to analyze theorem smart contracts. It follows the execution of contracts and what's cool is it can actually reach out and analyze contracts that are on the blockchain. You know, you don't have to just work with Solidity files. No, it doesn't give you back a solidity document like Porosity would but it actually could still step through the ones that are out on the blockchain. But in this case we'll be talking about pointing it to locally stored files. So it detects three valid issues and one sort of invalid one. So call stack, basically the call stack attack which we'll talk about later. It hasn't really been valid since EIP 150. But it also detects concurrency bug or transaction order dependence, time dependency attacks and re-entrancy which is the big DAO attack. So that's an important one and it's pretty accurate. I mean it looks like it has like less than 10% false positives based on other people's data and my testing too. It's just a little tricky to set up so warning you in advance. It complains about versions. It wants you to use old versions of things and then you have to do all that crazy stuff especially in Linux or forcing a version. But if you want my honest opinion, you can just use the latest version, get a few error messages and most of the time it just works anyway so don't worry about it. So just use the newest versions of everything. So to that end we're looking at hopefully getting a basic methodology in place. So whenever you start one of these the best thing to do is to talk to the devs. You know, if you come from an app testing background like I do, you'll find that kickoff calls, you know, who really likes kickoff calls, right? They're like the worst. And most of the times it's people explaining something to you as if you haven't seen it a hundred times before. When it comes to smart contracts, take the kickoff call because sometimes there's a really unique or novel thing they're trying to do. Again, we're in the infancy here. So you definitely want to talk to the devs in these types of hacks. They can show a lot of useful info. What does the contract do? You know, what environments required for testing? These are all important things, especially if there's any kind of like private or permissioned blockchain it has to talk to. So think along the lines of threat modeling at first. You have to kind of understand the application a little bit. Then after that you're going to want to plug it into something like Atom, Remix ID, take a look at it with highlighting, really understand if everything's okay. Try compiling it, make sure it doesn't error out. Maybe they give you the wrong version. You know, get that silly kind of housekeeping out of the way first. But then after that you're going to want to start to dissect the code flow. You're going to want to read any comments that are there. Use something like Soul Graph to understand it. You're going to want to run Oyente and cross your fingers and it doesn't error out. It often does. And then you're going to want to verify that the three that are real are there or not if you find them. But of course you're going to want to look at it manually too. And then you're going to want to check for the types of things that we're going to talk about now in the meat of the presentation. All right. So because of how popular the Dow hack is, we're going to start with this. So I'm not going to be dumping all the Dow code here because I don't even think these screens are big enough. And you're sure Lumvia will read it. So what I'm going to do is show how re-entrancy works with a really simplified sample I coded up here. And I call it re-entrancy, original name for a contract. And I'm just going to show the basic idea. So solidity is read sequentially by the EVM. So re-entrancy can happen if the amount transferred in a contract depends on a balance or state that's updated after the transfer is made. So because it's done sequentially, where you do your accounting is very important. Where you tell the program what all the values are. So in our vulnerable code snippet you can see the expendable tokens balance. It's set to zero at the very end. So the line I highlighted there with the little explosion. That's where the dangerous send or of money can go out. And then after that it's set to zero. So if you could somehow repeatedly invoke this function. Oops, sorry about that. If you could somehow repeatedly invoke this function you'll end up pulling the money out before it's set to zero over and over and over and over again. And something like that is what happened in the doubt. So let's see if we can't take some of this re- out of entrancy, you know. If you were to instead switch lines seven and eight. So now the exploding line does the accounting first. Then if any other contract or whatever was tried to try to pull from the if statement there. The money is already zeroed out. You know it's set up, it's all it's a one time thing and it's not going to go anywhere. So this accounting move means token balances are taken care of early. So even though this is tremendously simplified. The idea is that such a small little change can prevent a billion dollars from being stolen in a race condition. It's almost comical, right? You just don't see stuff like this in any other kind of programming. But it really is that simple.  We'll do a quick demo, see if the demo gods are smiling on us today. So this is on extended display so it might be hard to control here but if you could see that. So basically I can't see if it moved. So we have a simple program like the one I just talked about where there is a re-entrance condition present. So if you can see it there the balance is being zeroed out in the last line. If you can make that out. So if I were to run oyente against this I should be able to get it to flag the re-entrance. So I'll just do that real quick. I'll set it up and I'll execute it so you can see it. Okay. So once we hit enter it should run. Come on man. Yeah. I'm a bit of a comedian because of course it doesn't show the password. It's running and it shows the true condition to the re-entrance above. So it could run pretty simply. Because of this extended situation I'm not going to run the next part. But I was going to show you how ironically a bit of code that the developers wrote now errors out in oyente which is kind of comical because it's their sample code. But this one actually successfully ran and showed you. So you'd be able to go in and say why is it there and then you can make a tweak if need be. So all righty. So I'll just get that out of the way and we're back. Okay. So after seeing that you should be able to spot it pretty simply in a snippet of actual DAO code, right? So if you look here it should be pretty obvious. Because they're doing the withdrawal function first without doing all the accounting that follows afterwards it's possible for a re-entrance for a race condition to occur. And it's possible to keep hitting that red line over and over and over again and draining the balances down to zero. So that's the basic idea re-entrances. You just have to watch the careful ordering of the application. So what just happened last week with Parity Wallet it's interesting because Gavin Wood the guy that wrote Parity Wallet is one of the four developers of Solidity. So for him to make this kind of mistake was kind of embarrassing on an epic level. You know. So sorry about that Gavin but it really was. So the company basically tries to do browser based access to Ethereum to try and bring it more into usability. He wrote a multi-sig wallet and in theory multi-sig sounds great, right? Multi-signature, extra security. The only problem is Solidity there's something called visibilities. So functions have visibilities. In the case of functions the visibilities could be public, internal, external or private. The problem is if you don't declare them specifically they're by default going to be public. So if they're public that means it could be called internally or externally by anyone via message. So that's not what you want ideally in code. So you could see in pink how in the original version of the code there was no declaration made. In green you could see how they were changed to internal. Of course that happened after a whole lot of money was stolen. So, so the attackers could send a message calling the, it might be a little hard to see this, but the attackers could send a message calling the public init wallet and that function will override the original owner addresses with their own. So the attacker is then able to wrap that function call and pass in his own or her own ether address as the new owner. So in that first step you say hey this wallet's mine. And then with just another simple request, you can use the execute function. And when that happens your private key is used to sign an outgoing transfer for the balance of the account. If you do this ladder rinse and repeat for three major ICOs you get $30 million for your effort. Not bad for a day's work, right? Not too bad at all. So interestingly enough we used the term race condition before. Here this became a human race condition because a group called the White Hat Hacker Group they noticed this too and they noticed it was going on. So they quickly went in and started stealing the money from people who hadn't been attacked yet, from accounts and things that hadn't been attacked yet. And they siphoned off if you add everything up about $200 million and moved it to a wallet to protect it from this attack until the code was patched. But only a few people got that money back so far. So, you know, they promised by the 31st, but the White Hat Hacker Group, I mean if they don't come through that name is just going to suck. You know, they're going to have to come up with a different one. So, another popular attack was uncheck send. It was first discovered in kind of a goofy game but it's still worth talking about. Now you'll find this kind of thing in Ethereum a lot. In the early days of Solidity people would make these silly games like almost like Ponzi schemes or a digital chain letter in the blockchain if you will. You know, that's what they went for. So the idea was to claim a prize. So you would submit let's say one ETH to a game like this and that would make you king of the ether. Now back then one ETH was worth like nothing. Now it would be like handing over $200 but so you hand over this ETH and you're now king of the ether. So for someone to depose you they'd have to pay $1.5 ETH.  So you get paid kind of like a chain letter to be bumped out of the process then the next person pays more and the next person pays more. So if it's all fair it's a way to just keep throwing money for I have no idea why but that's the way the game works. So eventually you get more and more money each person who plays. So games like this you're sending using the keyword send and it acts like a method that's defined for every address object. But send can fail it's not fool proof. So ether stored in either externally owned contracts accounts are controlled by human or in contract accounts and these are controlled by a contract like that's what they call contract accounts. Metropolis version of the theorem is going to kind of abstract this but anyway. So in a contract account you can have a generalized error that would cause it to fail and that's basically what happened. Because any time a contract with that was called an error would occur a new person would become monarch but the old person would not get their money. So if you had been expecting to get 2.5 ETH or whatever at that point you got zip and now the new person was king and you were out 2.5 ETH. So again it's a goofy game it's not really serious but this kind of ability for send to fail is dangerous if you're talking about millions of dollars or something like that. So it's important to look for. So rather going to the whole long remediation code in the king of ETH error I just whipped up something a little easier hopefully to understand. So over here you could see the top code snippets called king of losing because ultimately like what's the point of this game right? But so if send fails over here the winner doesn't get the money but compensation sent will be set to true. Again it's the order that gets you in solidity the order of operations here. So if there's a fail it says that that person got paid but they actually never did. That's why at the top there it says compensation sent is true. Now again it can fail if it's a contract that generates some kind of error or some other kind of condition occurs. So to protect the price from being sent into the you know ether you can have it do a check like on the bottom. You can have it do an if check where if it's not actually sent there'll be some kind of thrown error. Now a thing about throw as we'll see in a moment it's being deprecated there's other forms of validation that I'll talk about in a moment but throw is just easiest to show in a slide like this. Alright so back to what was going on with king of ether. Those contracts were failing because they ran out of gas you know. It's a funny thing about gas. So miners are incentivized they're paid to run the Ethereum virtual machine in gas it's like a unit it's a small unit of ether and it fluctuates of course. So you get these little payments but just like a block shaped jeep a block can only hold so much gas and if you try to overfill it well you know you have an exploding station or something like that. So to find out how much gas you can ever have inside a block at any given time you could go to eatsats.net and it shows you a whole lot of pretty you know Hollywood hackery looking tables and things but in there is also an important number. Currently it's a little under seven million so that's how much gas can be in a block. So if you disobey that you're gonna have a problem something like an externally contract sent contract can fail and introduce errors like we said earlier. Alright so auditing contracts requires looking for places where errors lead to unintended possibly costly outcomes. It's not so different from other types of app hacking you know. So you have to look for the order of operations like I've said. If something fails due to an error nothing that comes after might run. So this could be sort of like a unintentional denial of service. There's a lot of problems in Ethereum where something layer out and then everything that comes after is just ignored which could be pretty dangerous. So in this case line 11 is trouble. This is an example taken from the Solidity Docs and attacker could trap the contract into an unusable state by causing the riches to be the address of a contract that has a fallback function which fails. So I think Matt talked about fallback functions a bit yesterday too. So it or even if it just consumes more than the amount of gas that's needed. So that way a transfer like that failing will cause the rest to not work. So to avoid this kind of problem you're going to actually set up withdrawal functions. Patterns in the application that allow withdrawals to happen instead of 4 cents to happen. So if you're overthrown as a riches for example you'll still get it because no errors can happen. In this case the worst you could do is cause your own withdrawal to fail which I don't know why you want to do that. But that's the safety of using withdrawal. Sometimes this is also called push pull instead of withdraw and send. But the idea is the same that you want to intelligently withdraw from a contract. Now before we talk about the next problem I just want to make a little note about the blockchain. There's all sorts of crypto involved in the blockchain in general. But what you'll find is most of the data that's actually put on a public blockchain like Ethereum is it's readable. You can explore it. You can analyze it. So yeah encryption protects wallets. It protects things like that. It doesn't protect necessarily the data that's going up on a blockchain. So games and other contracts that rely on any kind of like secret knowledge or winning knowledge can sometimes be fooled. So if you see people are making guesses on a chain that you're going to make in a game of chance you obviously wouldn't make those guesses if you saw they never won, right? You would kind of observe what other people did and then you would figure out and narrow your chances and make your own guess. So that's not really a great thing. The new metropolis hard fork is going to try and do something about having some kind of transactional privacy. So I'll talk about that in a second. Alright so we've seen examples of how the order is so important. So this was discovered by the guys that made the do-i-ante tool. Transaction ordering dependence. So the idea is that transactions can hit the blockchain in unexpected timing, right? You're not necessarily sure when they're going to go somewhere. So if you have like a simple puzzle like this, on the left there you'll see that the contracts private storage is allocated and initialized in line 8. And then on the right you have the executable code start. That's line 15 over there in which I marked. So transactions invoking puzzle will execute that part and it's anonymous by default. So sender repo, send ether data, it'll all be invoked and sent out. Now the contract owner can update the reward variable. Okay that's kind of like dangerous. You can literally say how much the reward is going to be.  So then after that you have that arrow going down where it shows the actual payout of the contract. Now what happens if a couple of blocks appear at the same time to a miner and someone is able to influence that and say oh well look someone's about to win. All of a sudden the reward is going to be one ether instead of a thousand ether or whatever. That's kind of a dangerous situation. You can have someone being very very dishonest in that case. They can present this seemingly fair game and then mess around with it. So Oyante is actually pretty good at discovering this kind of like forking possibility and detecting the transaction order dependence bug. The other function I mentioned that they find the other error call stack depth limit. This is no longer really a problem and most people don't know this but as of EIP 150 it's now become exponentially difficult to exhaust gas in this kind of attack. So what used to happen was you would have let's say because of the 1024 limit on call stack someone could create a contract that brings it all the way up to 1023 and then make a request which would be 1024 and cause an error. But because of the EIP 150 changes now what happens is it just becomes like I said exponentially more expensive to do an attack like this. So in the real world I don't anticipate call stack to really be a problem anymore. So it's sort of just like a historical footnote unless something drastically changes. So we saw that there's a lot of Pons of games and things going on in a theory for some reason. And one of the reasons they're so popular is because you could publish the source code, right? You could say to people hey look this game is fair, read it, read the source code, find something wrong with it. And of course no one really does but it's out there for anyone to analyze. So it's possible to make a mistake you know if you use highlighting it makes it easier sometimes to see when you're doing something wrong. But it's possible to make mistakes, some mistakes can happen. But it's also possible to trick people into thinking the code they're reading in a quick glance is actually doing something different than what it does. So in this case we have two separate variables you can see. So you've got payout cursor ID with an underscore at the end and you've got payout cursor ID with no underscore at the end. Talk about something that's incredibly easy to miss if you're just scanning through it. It's like oh yeah, yeah, you're just talking about payout cursor ID. So what happens is the first variable is getting incremented. But the line of code that actually draws the money out is taking it from the other one. So the person who's involved in a game like this thinks that they're contributing to a fair game when in reality their variables ultimately being ignored. And it's the other one that just looks kind of similar you might miss is actually getting all the money. Now again, this could happen accidentally, but in reality this is where the ethical and ethical hacking comes in, right? This is where you'd have to notice something like this is going on and be the one to raise the hand. So as I said before, it throws being deprecated. But input validation is a theme that should never leave any kind of app testing behind. You always have to do proper input validation. So now we've got these new, we've got Require which is meant to be used for input validation. It should be done in any user input. So if a user sends something that's not expected, it throws and the condition is false. So that's a good thing. You know, you're getting what you expect. There's also Assert which is neat because it can also check for internal errors or if a contract's reached any kind of like invalid state. So this is far more superior to just a simple throw. Although I didn't want to make examples with these two because I just get too long. So I used a deprecated throw. Sorry. It was easier to show. But this is the kind of thing to look for. Everywhere that there could be validation in a contract, there should be. Again, to prevent any kind of like denial of service or anything like that that we talked about. So a couple odds and ends here. Time step dependence. It's a little different than the transaction order dependence. The time stamp of a block can be manipulated. So watch out for any contracts that actually rely on a time stamp. It can be manipulated, it can be changed, it can be read within 900 seconds to have a different one be valid. So because of reasons like that, you want to make sure that silly things like that aren't being done. Because it's too easy to trick something that relies heavily on time. Business logic flaws and solidity. I expect this to be the next like big thing. People are focused on those little line by line errors. But sometimes you have to take a step back and say, hey, what's this thing supposed to do? And see that maybe it's not really doing what the developer thinks it's doing. So that becomes something worth looking at. Separating public and private, this is really interesting. And Ethereum has taken off quite a bit in the last few months since the Enterprise Ethereum Alliance formed. The idea there is a lot of companies are starting to have private permission blockchains internally that are then communicating with the bigger public block chain. And how you handle that public private data handoff is huge and I think could be a potential attack vector. So something that will be worth looking at in the future. I'm not sure if the JPMC quorum guys are here. But basically the quorum, they handle this pretty well. They have transaction senders that can use something called private for. And it can basically say, hey, this transaction is private for these people. And then after that it uses a hash of encrypted data only. And then it points to the actual encrypted data. So that way no one actually gets access to any information that they're not supposed to have, even though it's all in blockchain world, right? So it's a pretty ingenious way to handle it, so good on them. But basically when you're going in and doing any kind of like test of something that's new, some new interaction, you gotta look at those boundaries, which again kind of goes back to the whole idea of threat modeling.  How does it move through? Okay. So I think it's time for a lot more people to get involved. You know, I'm lonely. No. A lot of people have to be looking at this stuff. So I've become a DEF CON since the Alexis Park days, you know, and I know there's a lot of talent out there. So it shouldn't take very long for some of you guys to get spun up, Ben Gals, to join the fight here. You can get involved in making smart contracts more secure. Because despite its hiccups, I still believe in Ethereum. I think it's pretty incredible technology. They've never missed a dev milestone, which like, I don't know if there's any other project in the history of IT that's never missed a dev milestone. And somehow this young kid metallic made that happen. So good on him for that. So now we're entering what's called metropolis. And yeah, that's actually the 20 silent movie, you know, art. Not Ethereum art, but it's gonna be even more torn complete, if you will. It's gonna have a new revert and a new return data. It's gonna improve exception handling. So that'll be cool for security. Some account abstractions coming which will help protect wallets. It might even help protect them against quantum computing attacks in the future. Which is a whole other topic that if you want to, if you want me to bore you to death, stop me in the hall. And I'll talk about that. It's also introducing ZK snarks, which are these cool crypto primitives. Even though they're again primitives for now, it should in theory allow enhanced privacy and transactions going forward. So even though it's the public Ethereum blockchain, you should be able to actually have some privacy for the first time in the transactions you make. So that's a pretty cool thing. And finally with what's coming, there's Swarm. I mean if you haven't heard about Swarm, please go forth and Google. It's quite possibly the next amazing thing that you've never heard of. If anyone's watched Silicon Valley this summer on HBO, they did their whole trying to have a serverless internet by taking up little bits of data on a phone, storing it, compressing it. Well Swarm is sort of like that where it's gonna be using the EVM to have sharding and files located all around the world with address translation and everything so you can pull it back and get it. It's pretty amazing technology and once it's rolling full swing I mean it's gonna change a lot. So definitely try and get involved and join me in this good new fight. And if you guys want to keep in touch, please do reach out. If you have questions like some little bit of code you're working on, maybe I could take a quick look or something or if you just want to yell at me whatever, it's cool. So definitely reach out and thanks for coming.


So this is all my writing here. So it will be intensely boring if I just talk. So let's leave the agenda aside for the moment or leave this document aside for the moment and start with questions. If people who are here who weren't on the team this year or Gregor, you still have some questions about bursaries, then so let's open up to a question. Is anybody in the internet? Luca, hi. You need a microphone because we're sharing. Could you explain for those of us who are not part of the bursaries team the impact that cancellations have on you or the budget? So on me, it's just more work. It's basically so I send tools and it just means there's more batches. And there's typically some sanity checking back and forth with the rest of the team, which means there's extra males on the bursaries list in the sense that we start with the highest ranked candidates in some sense and work our way down. And so the question is, okay, guys, we have some more money. Does it seem reasonable that we fund these people who were ranked like this? I don't know, is that an answer to your question? It's not a terrible amount of work, but it seems to sort of be a task for 45 minutes or an hour a day during this period where we're dealing with it. Do you have a situation where you have cancellations that are fairly late and the next people on your list to whom you would have offered a bursary had you had the funding originally are unable to accept it's too late in the schedule, that kind of thing? That happens more rarely than I expected, to be honest. But I think that's one of the things that I mentioned here and we might as well talk about it now, which is the way we do things, the way that I've been doing things for a couple of years is to take the budget as a strict limit and never have more offers than that outstanding. Given the reality, we have a very strong expectation of cancellations and we can probably look at the data from previous years and every conference is different, but still we can, I think it would be reasonable to go to the DPL and say, this is our budget, we're going to overallocate by 10% or just to pick a number out of the air, but we expect to be within this lower number to give that kind of slightly more complex budget. I know that previous DPLs when we discussed that idea with them, so I think this when we talked to Luca, he said, I have no problem with funding it, but come back to me when you need the money. And I think, this was a little bit different because we were talking about working our way further down the thing, but it's closely related. I think that if we can offer more people earlier, it will be more efficient for everyone. I mean, less people will have to deal with last-minute panics. Yes, we'll have less rounds. So I don't know, maybe if you have any idea as DPL in the current hot seat, what do you think about this? Hey, hey, this year I guess we increased the budget for groceries by maybe 30%. Right, which was more like, that's actually another topic. So one topic is that we had this pre-process discussion with people and I said, okay, with this amount of money, we're only gonna be able to fund travel for about 45 people, that's my estimate. Is that okay or should we go to the DPL now and ask for more money? And well, I mean, everybody's in their own silo, right? And very stressed, so I didn't get any feedback that said, in fact, the first feedback I got that the number was too small was from you after we'd gone through this. So, I mean, it's not your responsibility to give me that feedback earlier, but somehow we could have also made things more efficient by asking for that extension earlier and looking at things and saying. Yeah, before making public the first results. Yes. Yeah. Very supporting of the idea of the, for example, the 20% extension over-committing, yeah. Because we can afford it. Right, even in the worst case where nobody cancels. Yeah. Right. Yeah. And for me, there is another question which is about the debt budget. There are things that should be constrained a lot because they cost a lot, like the venue, possibly. The accommodation, the conf dinner, whatever. And I think that the budget for bursaries should maybe be distinct from the debcoff budget because it's mainly with Debian money, maybe not. I guess, I don't know. I mean, it's, in practice it hasn't been a problem because Cathay wants to ask some questions. No, no, it's okay. You want to ask something, too. But you can. So, at least this year, there were no, there was no difficulties.  What I wanted to say is that we can increase, no, that's actually false because if you have too many people for the venue, you're screwed. Right, so one thing I tried to do this year is track better the sponsored accommodation because it does matter, right? It's 25% of our budget this year is sponsored accommodation. And it's not an expensive venue for accommodation. I take it off. All right. That's why we have discussions, right? Sure. But having the budget together, Debcoff and Borsari, has given some concern to local team because they are negative numbers. So, I think they will be more relaxed if we split and they don't need to balance the, also the Borsaris. Okay. Reminds me of my initial remark. People tend to focus a lot on the deficit of Debcoff. And this year, a big part of it is because of my decision to raise the Borsari's budget. Right. They might think that they were doing bad fundraising, which is not necessarily the case. Right. I mean, from my point of view, it's a question of how you present the accounts. Yeah. And so, whether this is a big change or just a way in which the budget is written up in terms of accounts. You were talking about separating the venue and the Borsari's budgets out. But doesn't the two interact so closely? Because if you're in a far away place where there's lots of travel required to get Debcoff, we're going to get a lot more people asking for Borsari's because it's beyond their normal budget. And at the same time, those far away places may well be a cheaper venue to have than if you're in a more populated area where the travel is cheaper to get to or the accommodation is easier. So the two really can't be taken separately. So part of it is the only way we do fundraising right now is through, or active fundraising, is through the Debian Conference sponsorship program. And that's part of why Borsari's has been included. I mean, there's no reason, like Borsari's is something we know we're going to have every year. We know we want to send as many Debian developers as possible. And that could, I think, if we were doing sort of global fundraising for Debian developer travelers, I think that would be fine and should also cover the mini-confs as well. Not just the one main Debcoff. But for now, I think, yes, it makes sense to keep it in the same budget because we are fundraising it for all as one block. It's okay that people are a little bit stressed about fundraising. Yes. I just wanted to, I walked in late. I'm sorry about that. So please tell me that it's been discussed. But when I walked in, you were talking about putting more diligence into the sponsored accommodation. Because in DC-15, that was like difficult to do. And now for DC-16, I think you improved the process and you had a closer watch. My question is how much do you think would it facilitate the entire process if we didn't have the concept of sponsored food and accommodation? But our attendees who are sponsored would simply receive an invoice. This is your invoice for attendance of Debcoff. You chose to be here five days at $30 each, so $150 is payable. And then they take this invoice and give it to you. So this means running more money through the trusted organizations or not? No, I think how you do the treasury, that's something separate. But it's more about creating a, lacking the word, an interface between... Awareness? Well, that too, that's a huge part, but it's also an interface. For instance, that would be compatible at some point in time with taking accommodation out of Debcoff, Oregon, entirely, if we ever wanted to do that, so that you put your promo code into that hotel's website over there and book your rooms, and then you apply for bursaries to give you the money back or somehow get a charge to a bursaries account so you don't have to shift the money all over the place. I'm simply wondering like, would it make more sense to simplify the interface between the applicants and you in invoice form? What I would say is no, and the reason is no is because I just about lost my temper today with people showing up at three minutes to two in my 12 to two document collection block, and that's with only travel sponsorship people to deal with. So the fact that food and accommodation sponsorship, which will probably continue to be a much larger number of attendees doesn't involve any time from bursaries slash treasury people at Debcoff is probably a strong benefit that I would not wanna give up. I think you wouldn't need to have this be a reimbursement process for the accommodation because all you need to do in advance of the conference is say this person applied for $150 for accommodation and food and then by checking that off you're essentially diverting who's paying the funds. It's no longer a receivable from. It could work, but the processes for dealing with the venue every year are very different and usually weird. Which is why I think the attendees should be dealing with the venue and we should have a standardized process. I think it could be difficult because then we are buying our attendees and for tax reason and trusted organization it could be very difficult. If we're in both it's okay, but if we pay and then they should come and I think it's more difficult for taxes reasons, but it's an idea. Maybe I could just, it seems like an implementation detail which is fine, we can talk about those but maybe since we're all here and this is probably something that the person doing it in a given year can decide. Probably the community as a whole doesn't care by their way, so maybe we could stick with it. I don't know, if you don't mind tabling it for now.  All right, so other things that people, other questions that people have. Fotis, is your name, sorry? Yes. Fotini, I'm sorry, I get your first and second name mixed up. You're just a spectator or did you want to ask some questions? Okay. At least I learned something. Now I can hopefully remember your last name since I've been publicly embarrassed about it. Okay, other questions. Luca again, these Canadians, I do not know if they're worth the trouble. When you said that you track the accommodation, what is involved in that and why is the accommodation tracked? So previously we have not done any, so for example in Heidelberg it was very different because the accommodation we bought in bulk. Is that right, Martin? More or less we booked a certain number of rooms. We booked the venue. We booked the whole venue, right? And so at that point the incremental cost to Debian of giving food and accommodation sponsorship to people until the venue filled was zero. So there was no real accounting to do. This year we pay per person per night. And for example, when Manny approached me and said, hey, paraphrasing, should we sponsor more people for travel? I said, sure, but we have to also take into account this will cost extra accommodation and made some estimate about if we sponsor these 10 more people then it's gonna cost this much more in accommodation. Again, having come late to this discussion, please tell me to read the documents or whatever it is. I have a couple of questions, a couple of points. One of the things that I see there is the always cancellations overcommit by X percent. So we agreed that that was a good idea.  I do wanna say that it worked really well this year. I think in the sense that when there was a cancellation you guys, you were really quick at pulling in the next people. And if that process had been stretched out to a couple of months before, I think it would have been highly successful. So I think that was really, really good. So I could just comment on that. The reason that that was possible is that we did one static ranking initially and used that ranking for, so we didn't have to have discussions of people's ranking in order to reallocate them. Right. Did you discuss about what went well in the process and what didn't? No, we've mostly been complaining, so. So I had the impression maybe just because of who was on the diversity team. So let me not forget anybody, Gregor. We had Gregor, Hogar, Karaj, Sledge, Laura, Tiago, Martin. Sorry, Martin, I keep doing this to you. Martin really was helping. I think that's every, did I forget anybody? All right, so if anybody was forgotten, feel free to curse me out on IRC and then Nicola will be happy to read your curses out. See, he's nodding. French curses preferred. Okay, so I think that group of people for whatever reason was good at thinking about different ways that people contribute to Debian or people who had contributed some but showed some potential or were bringing some diversity to the conference. Not all of those people that we offered managed to make it. There were several people that were funded that canceled several people from Africa that we funded that canceled for personal reasons. It's not perfect but so that I thought worked well. I think part of the reason why it worked so well was because you made the decision to not let everyone rank everyone but you had two people, two from the bursaries team on each record so that there would be like some sort of weighted opinion and that as a result meant that for the entire process of ranking like however many people there were, I don't remember, it took me less than an hour. Because I knew most of the, maybe I was lucky, right? But I knew most of the people on the list and I didn't have to do too much research but it was really not that much trouble and so next year we can definitely tell this as a success story and hopefully get even more people because there's gonna be even less work and to get the static list which was really, really helpful. So one comment that we were discussing previously, I think during the cheese and wine party was at some point I suggested or some of us agreed that it would be good if people applying for travel sponsorship were not on that year's bursaries committee and I think everybody agrees this is a good principle. The conflict of interest is pretty obvious even if you recuse yourself from specific cases, the fact that you're involved with discussions of other people that the conflict is obvious. It does make it a bit harder to find people and this year was particularly challenging because so many DDs reasonably felt they needed help getting here which Andy already mentioned. So it's a reason, I think that more than the workload made it hard to and maybe I was a little pessimistic about the workload. I don't know Gregor, do you mind saying how much time it took you to do or what was your experience? So my experiences are quite similar to what Martin said since basically you were running the show in a perfect way. We just had to open up this spreadsheet and go over our, I don't know, a dozen or whatever person. Yeah, it was more like three dozen, but. Three dozen was okay. I didn't know it. Yeah, so I guess the first batch was, you said an hour, yeah, maybe an hour and a half or something like that. And then those two or three additional persons. So it was really not much work for all except for you. Yeah, so I think that's something, not just because I don't wanna do all that work, but I think in order to make it possible for various people to do bursaries, I think it's not healthy if bursaries is one person and also there might be other things that I could be doing. So we may think about how to make me not be a blocker in the process. And one thing that's worked reasonably well during GEPGONF is that Nigel and I have been in tandem working through the reimbursement process. So I think two or three people could easily still keep coherence, not have any miscommunications, but also spread below the bit in this sort of processing incoming requests, formulating questions to the bursary committee, giving a little background saying, all right, here's where we stand. What should we do next? So that was a way to make it a more... I understand that a lot of the benefits from the static list that we got was came out of that Python script that you wrote. So you've already started to replace yourself with a small script, right? I think we should take this one step further because I thought that the CSV file sending back and forth thing was kind of painful and must have been really painful for you to merge all this stuff. No, it was all easy. Okay, but if you had decided to take a hike or spend the rest of your life on the tree, then we would have had the problem to consolidate or whatever, pick up your workflow. We should put this in or close by our conference management system somehow. It shouldn't be too hard considering how the process is mostly automated. And I think it would be even easier if I could just log on to the website and quickly, while I'm on a train for 10 minutes, like two or three people and check it off rather than save local files and so on. So I have a strong bias for offline operation, but I don't think that that should necessarily guide the processes. So whatever works for the team as a whole is fine for me. So there in fact, there is code to do the merging that you think was hard. So there's already scripting for that. I mean, yes, it could live in the conference management system if the conference management system wasn't replaced every year. So I personally am not willing to invest in the DevConf conference managing system, management system until DevConf uses the same one two years in a row. Oh, you mean summit? Pentabase? No, good point. So that's just my, I can't invest time in something if it's throwaway code. I wasn't trying to get you to commit to it, more figuring out whether it would be helpful. I think that in the long run, I mean, we might see this offline version as a kind of prototype and we might integrate something into the conference management system. One thing that's a little bit tricky and maybe I'm oversensitive is confidentiality issues. So the bursaries ratings in previous iterations were available to everybody who was admin on the conference website. And you have to decide if that's okay or not. And the problem with Penta, some people must still remember Penta, I know Martin does, is that these administrative privileges were never revoked. So the list of administrators strictly grew over time. And so eventually it became more or less 100% that if you or your closest friend were applying for bursaries, you could browse the team's ratings. Okay, I mean, if people in general can live with, on the one hand, it's clearly not ideal, right? And on the other hand, we always have this issue with system administrators and we somehow trust Luca, so I don't know. No, I mean. He's from Canada. Yeah, so. It's meant to change in the future. So I don't know, that's something to think, I would say that's something to think about in terms of integration with the conference management system is there is some advantages to being your own little kingdom, which is, but there's this trade-off too. There is an API and so you could implement it as a microservice outside. There's probably technical solutions to this social problem, yes. I have another question. In the past, we've had very few cases, but we have had cases where people requested sponsorship and then didn't show up to the conference, or otherwise like behaved in ways that were not, you know, I mean, obviously, if you get the measles two days beforehand and then we're glad that you don't show up, but if you just don't show up, which there was at least one case last year. Do we have any processes in place to handle that? We don't. The first thing that I started tracking last year, and please, I hope I remember to do again this year is Canvas people on volunteers, how effective, how helpful they were. And some members of the committee told me that that information was quite helpful in terms of evaluating this year's nurseries, but that's only taking the positive, you know, I'm a positive guy, but yeah, I don't know. There are all kinds of issues to think about once we start tracking these things. If we have, I mean, as a sort of organization of open and good people, if we have secret blacklists, it's not that we can't do it, but there's complications. So yes, we need some way of having a collective memory that doesn't get us into legal trouble. Just, you know, German law is crazy or is very protective of privacy. So we can't keep it on a server in Germany or something? I mean, I don't know. No, I'm, so more seriously, we need some way of some process to, and I don't know what that process should be exactly. I don't know if blacklists is the way to go and I don't even know if that is the reason why I asked the question, because what I really would like to have is not that we can tell the person, like, ha ha, you didn't come last year, so we're not going to sponsor you. I would like to get those people who apply for sponsorship to be more diligent about their application, so that at some point in time, in the registration process, we actually get more reliable numbers than we do in the current process. Because currently still, I think a lot of people just sign up, do the whole sponsorship thing, and then, you know, like, if something inconvenience happens or they didn't actually mean to attend in the first place, they just canceled relatively late in the stage, more work for us, less money available to other people, and so on and so forth. So if it became clear that, you know, if by the end of March you're not committed, or you'd like pull back later on, then this is possibly going to negatively weigh into your future evaluations. So in fact, some people who canceled this year said, ask that question, will this negatively reflect? I think we'd be in a better position to take some kind of moral high ground position if we managed to get the initial offers out earlier. So in order to tell people you are bad for not cancelling at the last minute, there needs to be a distinction, a real distinction between finding out and cancelling, but I mean, we could have some kind of confirmation process if we, for bursaries, right? I mean, we could minimally ask people, let us know if, so currently we say, let us know if you're not going to accept this bursary. And so that has the failure mode of ending up in people's spam folder and assuming that they're coming when they're not. So the other failure mode is people, we cancel people sort of when they really intended to come, but just didn't manage to deal with it now. Should I, it's me? Fine, I'll stop talking. So we only have five minutes left, so there are other, Medi wants to. Okay. So you added this question about requirements for depth camp funding. Yeah. Is this this? Yeah, so this is something that- How about your plans on this question? Right, so this is, didn't work so well this year, in my opinion, because first of all, I think there wasn't a clear under collective understanding on the bursary's committee of what are our requirements for granting depth camp sponsorship? And that meant, and so I personally thought, and when I wrote up the instructions for people applying, which many experienced DD's manifestly did not read, I said, if you're applying for depth camp sponsorship, please make sure you, in this text box, tell us your depth camp plan. Where the text box was somewhere else? So yes, you had to sort of switch back and forth, and that's an issue with the form. Basically, there was a question of how can we construct a process that requires zero hours of web dev, and so that was pointing people through some instructions to read. So I guess my idea was, well, if you didn't bother telling us anything, we'll just reject your depth camp sponsorship, but the committee told me I was being too strict. So that's fine. I mean, that's why there's a committee, and not just me, right? But I guess, I don't know, let me take one minute of our remaining time to articulate why I thought this was even reasonable to consider denying depth camp sponsorship to people that honestly, we're pretty confident we'll do something reasonable in depth camp. So offhand, it sounds a little bureaucratic and insane. The reason is I wanted to try and create a level playing field between people new to the community and people who everybody knows. So the people who everybody knows, if sort of get a free pass here, I guess we can decide as a community that that's okay, but it does sort of, I don't know, at the time it seemed like it put the people who were unknown at a disadvantage, just by putting the other people at a relative advantage. If you have still time, I have two questions actually. So you've seen the case of someone accepted on the schedule with the talk, but not being sponsored. Yes. Is that something that we should work on in the future, or is that an issue? So first of all, the person in question should have been better at filling out their application form and at least said that they applied to give a talk, then we would have contacted the content team for sure. If they'd said, I've applied to give a talk, we'd say, hey, should we fund this guy? He says he's, if you tell us to fund him, we'll fund him. I mean, that was my position with speakers this year, was if the content team wanted somebody, then that I considered a pretty strong endorsement. I mean. I think his point was about the schedule or some talks were published before the sponsoring were... Yes, so there was a potential communication problem, for sure, like we didn't know who was sponsored or who was accepted for talks or not, but I'm not sure the content team knew either who was accepted. So Allison is shaking her head and saying, that the information just wasn't decided yet. So I don't know what could be improved there, except... Maybe work on those. I mean, I guess in the no mail, there's a line which says, if you think there's some issue here, please contact us. And I think rather than, I guess, although it's a little less transparent, I think it would be better to take this up with bursaries than to make a public issue out of it, only because I think it looks kind of bad if people are not funded, they make a big scene publicly and they're funded, there's not a precedent we want to encourage. So this is something we've actually talked about in terms of website tooling. If you could get a simple cross-reference list of people who applied for bursaries and submitted talks, that would help enormously. Because you did actually, for the people who said they submitted a talk, you did email us and ask, are these people going to be accepted? And even though we hadn't finalized the process yet, we knew those were good enough. So we looked and we're like, yes, we're going to accept these and we let you know. So where we had the information, I think we did the right thing, but it's a matter of surfacing the right information. And that's a pretty simple cross-reference because everybody's using the same either Alioth account or Debian account. So it's possible.  And as Martin suggested, if the bursary process was a little more integrated with that, then, or I just asked for the right fields in the CSV dump, right? I mean, part of that was me not thinking about this. I don't know how technically feasible that would have been, but I didn't ask for that information as part of the information that I got from someone. So we can improve it technically and not just socially. My second question was, it wasn't clear for me who was handling the diversity and GSOC applications with respect to bursaries because there is some overlap. So it was pretty unclear to everyone involved, I think. So part of the issue was for whatever, well, this GSOC thing was a surprise for everyone and then for what, I guess to decrease stress on the DevCon team, this was originally going to be handled outside the DevCon budget, right? So that was supposed to be invisible to me, to our team. Right, yes. Right, so it's complicated, right? And this is, we're out of time. Okay, so, well, you know, the hallway track continues. So thanks everyone. This was a good version of this ball. There was lots of interesting discussion and thanks for turning up.


Hello everyone. I'm going to present our paper entitled as Consolidating First Order Masking Schemes, Nullified Fray Shandomness, which is joined with Amir and I'm Ayn and I have the pleasure to present this paper in this video. Masking schemes are one of the most popular compromises against site analysis and which is based on a randomizing sensitive data during the execution of the cipher. So in the masking scheme, we usually divide the sensitive variable to some shares and which may force the adversary to recombine the shares to recover the key. But how we can evaluate a given mask design? So to this end, probing model was proposed. So adversity can probe the intermediate values and each probe are exact and independent. And it has been shown that security in this model also provides security in other models. And if any combination of intermediate values does not reveal anything about the circuit, then design is secure against the order side channel attack. And due to its simple basis and due to its simplicity and its abstraction, probing model is basis for many problems in site channel analysis. However, it does not properly work in hardware implementations. The reason behind these is glitches. Glitches are unwanted transient at the output of a combinatorial circuit. And this fact usually or mainly due to the unbalanced path of the input of a combinatorial circuit. So in this model, when a probe plays on a gate, it propagates backward up to that synchronization point. So here is a simple logic circuit. So if probe the output or one of the output, the probe propagates backward and the adversity have information about the odd for input bits are involved in the calculation of original probe. So to this end to mask hardware platforms, main methodology has been proposed. So one of the first methodologies that are immune against glitches is terrestrial implementation or TI. TI is based on three essential rules and condition which are called correctness, non-completeness and uniformity. And basically in this design, we made a design which is correct and non-complete and by adding some correct terms, we try to find uniform sharing. The number of input shares is defined based on the algebraic degree of the target function and also security order D. However, in D plus one sharing, we use only D plus one, so it's independent of the algebraic degree of the target function and also the structure of D plus one sharing is something like this. I brought a very simple example. First order secure to input AND gate using two shares. In D plus one sharing, the mask usually is divided into two parts. One part is called component function. Now here we have four component functions and I showed one of them with the box. The result of each component function should be stored in a register and we have compression layer is basically the combination of some component function by X or to generate two output shares in this case. But for some Boolean function like this one, hobby plus C, it has been shown that it's not necessary to use fresh masks. So in this case, C, which is a variable of the target function F, can be seen as a fresh mask and then it can be shown that this design is each extended problem secure and also uniform. If you replace the C with B, then we want to see whether it remains secure or not. So to evaluate the security around this table. In this table, you can see each intermediate variable here. So if adversarial probe, one of the intermediate values like X prime 0 to X prime 3 and for example here X prime 0, which is an output of first component function, you can see that if I fix the unshared value R and B to anything and then C probe up and I go over all valid input shares, then I see always 3 0 and 1 1. So the adversarial, regardless of the unshared value, see the same probability distribution. So it means that it's completely independent of the R and B. I can explain this one in other way because every component function is non-complete. So in this case, it receives only O0 and B0 and O0 and B0 are independent of O and B. So probing any component function output does not reveal anything about the secret. So what if adversarial probe, one of the outputters, so in this case X0. So in glitch extended probing model, it expands to 2 probes as you can see here. So to evaluate the security, we have to see this part of the table. And as you can see again, regardless of the unshared value R and B, the probability joint distribution is always the same. So we can conclude that this design is always Q and it doesn't matter the adversarial probe, which part of the circuit and replacing the C with B also leads to secure design. So this means that we can make a secure mask implementation of 2 input and gate without any mesh mask with only 2 shares and by only inverting the R in this function. So R bar B plus B is already all there. And if you follow this construction that I show in the last slide, then we can have a secure design. I would like to stress that this is the first time such a mask implementation is presented in the literature. So we are going to make it a bit generalized. So if F is an arbitrary 2 input function, which is a quadratic, then we have always the term R bar and the shared variant has 4 quadratic terms that you can see here. So due to non-completeness, we should have at least 4 component functions. So to find a secure design, you follow the below steps. So basically we made the set F0, including all possible 2 input constant 3 coordinate functions for F0. So in this case for F0, it takes all 0 and B0 as its input to have 4 different coordinate functions, namely all 0 B0, all 0 B0 plus all 0 and then we have all 0 B0 plus B0 and all 0 B0 plus all 0 plus B0. So each set has 4 different coordinate functions and the set F0 has 4 different elements. We can do the same for other sets and make F1 to F3. And then we search for tuples F1 and F0 if we suppose that the component functions 0 and F1 are compressed. So we are searching for tuples, which leads to identical joint probability distribution. As I've shown in the last slide, we should make sure that if the adversity prone of the output shares and it expands to some of the component function output, we should always see the same joint probability. This ensures the security in which extended probing mode. And then they are X or I mean the output of F0 and F1, X or together, we should see a balance function, which means that it should yield to as many as one as 0. This is a necessary condition to achieve uniformity. So if any of those uppers fulfills both conditions, we should add them into the set F01 and do the same for the component function F2 and F3 and make the set F2 and 3. And the last step, we search for the tuples whose X or makes a correct sharing. So in TI, in the first step, we have something which is correct and non-complete and trying to add correction terms to make it uniform. However, in our algorithm, we have something which is non-complete and uniform. And also a glitch extended probing secure and then we try to find the correct sharing. So we can make it a bit more generalized for any two input function. So then we are forced to use at least eight component functions because we have a QB function and we have three inputs, each input is shared with two. And then we have two to the power of three, which means eight component functions. So the ester is pretty similar to last one. We make sets F0 to F7 and each of them should include all possible three cubic terms. Then if we assume that F0 to F3 are compressed, we search for tuples that again has the same identical joint probability distribution, which again is short security, glitched in the probing model, and then their X or is a balance function. We keep those tuples fulfilled both conditions and add them to the set F0, 1, 2, 3. We do the same and make the other set and then we try to find the correct sharing. So in this way, I found many solutions for three input end gate without any fresh masks. So this is also the first time such a construction is presented. So let's make it a bit more generalized and for more complex Boolean functions. We have a function F, which is a constant free as always. If it's not, we can remove it at first and then add them in the shared mask version of the target function, which is F here. So again, because we have four input and also it's cube function, we can share it or we can realize the share variant with two input shares with eight common functions. I would like to highlight that this is not the only possibility and we have some other possibility to share on or basically distribute the share term into component functions. And the algorithm is pretty similar to three input cube functions, so I'm not going to repeat them, but we have more search space. It's harder and we need more time to apply algorithm to such functions, which has four input and with algebraic three of three. So we take the middle S box. And we know that it's for bit to four by Jason and each coordinate function is at most cubic. So we can apply an algorithm to each of coordinate functions. And as you can see, we have many solutions for each coordinate function. So, for example, here for one coordinate function, we have about 70 million solutions, which is secure under each extended promoter and uniform and also of course correct. But it doesn't mean a combination of these solution leads to a jointly uniform solution. So to find the joint uniform solution, if we take two solution and then check the uniformity and if it was uniform, we add the third one, or we discard it. So in this way, we discard the non-uniform solution earlier. And if the third one is jointly uniform, then we add the last one and check the uniformity. And keep in mind that the number of possible combination in middle S box giving these numbers is very high. It's not possible actually to check it all in months. So we found the solution and actually many solutions for Midori. And based on our findings, we realized a two-share round-based implementation of Midori, which supports both encryption and decryption function without any fresh mass and would not stress that this is the first time such a construction is presented in literature. So we have applied our technique to present espouse and we also found millions of secure solutions on the clock beach probing model and also uniformity. And then we have designed a two-share serial implementation of Midori to make it fair to compare it to a state-of-the-art. And again, this is the first time such a construction without any fresh mass using the minimum number of input shared is presented. We also applied our technique to print S box, but it's not as I said before that the former cases. So both S box and S box inverse are used in prints. And as always and like in former cases, we have many solutions for each coordinate function. However, we found no solution. We jointly informed for S box or its inverse. So basically, if you take three output shares, then it's jointly uniform, any combination of three. But then we add the fourth one, then it's not uniform. We have already searched all the space and we didn't find anything. But based on these constructions, we implemented both S box and its inverse. So here, and we used the component function and the register and the compression and we also have a state register here. And this design, we didn't see any leakage in practice. I mean, getting 100 million traces from FPGA, we didn't see any leakage and this is our observation. And we think the diffusion layer here plays a role. So if you compose a couple of S in a row without any diffusion layer, we have more leakage. But if we add this diffusion layer here, then the amount of the leakage is too small to take in our cases. So this is only our observation and not a proof. And we also applied our technique in ASS. So basically, two tower field approach and use it. So we have three multiplier here and inverted here with the 4B to 4B function and a square scale function, which is a linear. Then we have two sports. So to apply our technique to these functions, we integrate all these functions and make one function which is 8B to 4B function and we call it a square scale multiply. And then we have an inverter here, which is a 4B to 4B function, which is at most cubic. And a square scale multiply is quadratic, each coordinate function. We have multiplier here, which is 8B to 4B function. And each coordinate function is quadratic. So we can use our algorithm to find the solution. And actually we found a secure probing, sharing, and also a uniform for each of them. And based on that, we introduced two designs, one take one fresh beat here to make it secure and uniform. And then we found the solution without any fresh mass here. And also the multiplier, two multiplier here is also uniform and probing secure. And even though these 4B and these 4B, which is output of this multiplier and this multiplier is uniform, these 8B is not uniform. So you can get rid of these one fresh mass here by implementing the square scale multiplier function twice in such a way that it provides two different outputs. And then we have to implement inverter twice. And then we have a multiplier here. And again, the output of each multiplier is uniform, but it's not joint uniform when considered these 8B. So I should highlight that this is only the inverter, so we need an input affine here. So let me show here, which is easy. We apply the input affine as to the result of the register and then add it in front of it. However, we need output affine here, but we cannot give it right away because it's not uniform. So again, we are going to make a use of diffusion layer of AES. So R prime, B prime, C prime, and D prime are the output of the inversion, the mass inversion. We need to apply the output affine and then the mass column, and x, y, z, and t are the output of the mass column. So we divide this or basically decompose the two functions, mass column prime and beta. And because all of these operations are linear, we can change the order. So basically apply the beta first, and sort the result in the register, and then apply the mass column prime. So as you can see here, beta has only 0 and 1, and does not mix anything from the same S-box. And for example here, you can see the addition of other versions output as a fresh mass. So then x prime, y prime, z prime, and t prime become uniform individually. So of course if you consider all of them together, it's not uniform anymore. So then we apply the mix length prime and output affine, and then we have the output of the mass column. So here you can see the general structure of the AES encryption, which is a byte serial implementation. We have key registers, we have a state register here. We apply beta, store the result in the register, and then output affine and mix column prime. And the result of the mix column prime also register here. So because we didn't apply the output affine right after the inversion here, we need to apply output affine inverse to make sure that the key expansion is correct. And as I said before, we have input affine here, which is stored in the register, and then we have the inverter here. And again in our FPGA analysis, we didn't see a leakage. And we're seeing again this mix column and beta function and mix and prime play a role and make the leakage too small to detect in the FPGA evaluation. So here's the result. As you can see, Midori has a bit more area overhead compared to the state of the art and also has a bit more delay. But an advantage, it uses two shares, two input shares, which mean that it needs less initial masking. Our present, it has lower area overhead and also roughly the same delay and also is two shares compared to the state of the art, which is a two shares. Our prints designs has no freshness and basically it doesn't need any fresh masks. And the area overhead and delay is also roughly the same with the state of the art. And our AS, we have two variants with one bit of freshness per SBOX and per clock cycle because we use only one SBOX in bytes of implementation. And we also have no freshness design, which is a bit larger because you have to instance of some function twice. And you can see here, we have the smallest AS implementation here in the state of the art and we use basically one fresh mask here and no fresh mask here. So as an evaluation, as I said, we verify the security of our construction using silver. All the designs are secure under the glitch and the probing model. And as I said before, some of them are not jointly fully uniform. And but for trains and mid-air, we found a solution which is jointly uniform. And because silver, it is still possible with silver to analyze the full encryption, we perform practical analysis on FPGA and security FPGA and getting 100 million races. None of them, including in AS and prints, we didn't see any leakage. So this is my last slide. And in this paper, we provided a methodology to realize first-order two-share masquerization of nonlinear function without any fresh masks. And we introduced at first time the SQ AND gate with two input and three input with no fresh masks. And also the media response and presence box. And we also applied our technique to prints and AS and didn't see any leakage in practice. And our designs were the best of our knowledge or the only one which used only two-share without any fresh masks and without applying changing of guards. So thanks a lot for your attention and watching this video. Please don't hesitate to ask me if you have any questions or if you have any suggestions. Thank you so much.