Hello, my name's Mark Davy. I'm the Chief Executive of the Youth Adventure Trust. We've been established for over 25 years and during that time we've supported thousands of vulnerable young people to overcome their fears, to build their confidence, their self-esteem, to build their resilience and mental toughness. We do that through a series of outdoor adventure camps, activity days. We also have a mentoring programme and a bursary scheme. All young people should be given the opportunity to engage in adventurous outdoor activities, to unlock their potential and to lead positive lives in the future. We're really pleased that Ellersbrough have nominated us for the Explore Fund. We've been working with them for a number of years on one of our mountain challenge fundraising events. So it was great to hear that we've been nominated and it's made a huge difference to what we've been able to offer our young people this year. The North Face Funding has enabled us to provide a critical support to vulnerable young people at this particularly challenging time. Many of our young people have been extremely isolated and we've been able to provide mentoring support, one-to-one support for those young people, a whole summer of activities that they've been able to really engage with. So it's all been extremely important.


How's it going everybody? DottoDoy here back with another Dragon Ball Fighters video, and this time we are talking about a much requested topic, that being our final tier list for Dragon Ball Fighters Season 2. The odds are pretty good that they will reveal something going into the World Tour finals sometime in February regarding the future of Dragon Ball Fighters, but for Season 2 this is pretty much the end of the line, meaning we have had a long time with each and every one of these characters, including DBS Broly who is the latest inclusion, even we have a couple weeks with them now, so this is really probably the best time to be doing a video like this. Quick disclaimer, as with all tier list videos, this is just going to be my opinion on the characters in this game. Tier list can be in a lot of different things to a lot of different players, top players, beginners, middle level players, and even within those groups people's opinions usually vary, so definitely let me know down below in the comments what your thoughts are on Dragon Ball Fighters and where you think some of the characters should land in terms of strength. Oh you'll notice another thing I did here was I kind of limited to only C because even the worst characters in Fighters, due to the nature of it being a tag team fighting game, aren't really bad and the system mechanics in Fighters really lend themselves to making that if you're just a good player and you know your way around on defense, you know you'll get the job done with pretty much anybody here.  With that said though I think it's pretty easy just bop and bop. Those are the only two characters I think you could put in C tier, actually hold on let me get him a little friend here, Blue Vegeta. If I were to organize this by strength I would probably put it like something like this maybe, but yeah this is probably the level of strength I would put in accurate C tier. Blue Vegeta I think you could just use some additional tools, nobody's really playing him at a high level you just don't really see him too often. Again it's not like he can't get the job done, he has a low hitting too well, all of the normals of a Vegeta, but his assist is a little underwhelming and just his toolkit in general is a little underwhelming, especially when compared to other Vegeta's in the game that are just so much better that even if you're a fan of Vegeta it makes picking Vegeta Blue a little harder to do. Krillin on the other hand has some really strong components and I do not think he's the worst in the game at all. In fact if I was doing this entirely based on my heart and not the fact that there's probably a Blue Vegeta main out there that also feels this way I would say Krillin could be in B tier, maybe low B tier, but you know he has a lot of strong stuff, his post vanish game, his Kamehameha, all of those things are so so good, but the fact that it's a team fighting game and Krillin's assist is just super awful, really makes him difficult to use, because when you switch him out it really honestly feels like you just have a dead character. And then the character that I have in Dead Last that is Jiren, what an unfortunate character Jiren has turned out to be. He just struggles in so many areas, even in areas where it seems like even the devs of arcs are like yeah uh yeah Jiren kind of sucks. And these areas I'm specifically talking about are his counters which people can just vanish out of pretty much just all of them.  And then you do his range counter and people can vanish out of that and you compare that to a character like Jiren who also has a key blast and beam counter and he's fully invincible and it locks on and he can combo. Why? Why is Jiren so privileged compared to Jiren? I mean Jiren should also work like Jiren to be fair, maybe not in the exact way, obviously you don't have to make it appear behind them, but just let Jiren get a combo off both of his counters and even then I don't think he would be too too good, but uh it would definitely improve him a little bit overall. Some of the adjustments I could see them making is definitely tweaking the speed of his 5H grab, that's another thing, he doesn't have a standard 5H where instead he just gets a command grab, but it's painfully slow compared to some of the others in the game so it overall just kind of feels like a desperate move if you ever want to go for it, just like wow that Jiren player really clicked that unsafe button, that's the only way I could see it really catching people. And now we move on to the top of the top, S plus, why did I separate S and S plus? It's just because I feel like there's a small dividing line between S plus and S and I think it's pretty obvious, but we're just gonna go ahead and pop them right in here, who are the three characters I think are S plus material? You got the number one in the game, GT Goku. People are gonna disagree on this, a lot of people think it's Kid Buu, but I feel like what you're getting for GT Goku is just, it's a little too much, honestly GT Goku is the complete package, this man has everything you could want, slide him on any team and Kid Buu has some of that as well, that's why he's also S plus, but I don't know, I feel like he's less of an overall good tool and I could see people disagreeing with me on this because I feel like Kid Buu does a lot too, it's hard, I think they're next to each other, but I feel like Goku GT just barely gets it for me and maybe that's just because I find him a little more annoying, but yeah, they are both S plus. The last S plus character for me is Teen Gohan, I hate this guy, I hate this character, but I hate defending against him I should say, he's just too good dude, he's got the damage, he's got the combos, he's got the neutral, this character is just really really nice to play now, I think he's in a good spot actually, I would probably tone him down all things considered, maybe he's in too good of a spot, but part of me thinks it's really nice to see him so high up, when at the beginning of Fighter's lifespan he was seen as a complete non-factor just because Adult Gohan was so much better than him and S, that's right, S I'm gonna start off with Bardock down here, people are dropping Bardock nowadays, but I don't think that's really a reason to sleep on him, there's a reason Bardock is Bardock and we all know and love him, even now I still view him as the epitome of a Fighter's character, this guy just has every tool you could want while still doing all of the basic stuff really well, whereas Goku GT is like that but also like they gave him a spear bomb for some reason and made him shorter, Bardock again is probably one of those characters we don't have to talk too much about, but he's very approachable making him great for newcomers to pick up and dip their toes into Fighter's more hardcore side with all the stuff he can do, so if you haven't played Bardock and you're new to the game I actually would recommend picking him up, it's hard to nerf Bardock as well, I don't think there's much they could do to him without completely killing his character, but it'll be interesting seeing what they do with him moving forward if they continue with this game, as for other S characters maybe this is where most people will start disagreeing with my list because I'm actually going to throw a couple contestants up here, we got adult Gohan, that one I don't think people will disagree with but I'm also gonna throw in DVZ Broly and I also just have to throw in Super Saiyan Goku up here dude, Super Saiyan Goku has proven that he is here to stay, he is definitely the Ryu of Dragon Ball Fighters except he is much more of a multi-tool, this man can go on any team, he's got the classic beam assist, but his simplicity really doesn't hurt him when he's out on the field as well, he has a great Keyblast game, he can play just about any aspect of Fighter as well, and you've seen this character make comebacks, there's a lot of people joke about Super Saiyan Goku being a comeback character and it's because it's entirely true, 1v3 with Super Saiyan Goku ain't even that hard if you have Sparkin by your side as you can really just approach just about any character and really make them play more your game than theirs. DVZ Broly I have up here just because this dude is an absolute monster, he'll chase you down, he has a great amount of armor moves and honestly even more than that it's his Keyblast game, the keep away potential with Broly is so stupid, definitely not what I foresaw when they were making this character putting out trailers and stuff because he does have grabs and armor so I thought he'd be a grappler, but then they decided to put some armor on those Keyblasts too, just the ability to overpower anybody else in the Keyblast game, make them want a Super Dash and punish them appropriately after that is a huge nuisance to deal with. And Adult Gohan out again, we don't really have to talk about him too much, he's pretty much just Teen Gohan with a very good level 1 Super, still insane what this character is able to do off of a level 1 with the snap stuff, so Adult Gohan probably has one of the best level 1 Super's in the game with that power up. I don't know if I really want to do this, I just thought about this now, but I think I'm also going to add base Vegeta to S, I don't know if I want to stick with that though, but he is a very solid character, I'm going to do it just because man he's so good, the Keyblast, the kicks, it's crazy how slept on this character was until a few months ago, but now that he's here I definitely think he's proven he has the tools to stay, I don't even think they really need to nerf this character, I think he's in a great spot, I could move him down to A though, I'm going to keep him in S for now, I'm going to keep him in S for now, we'll see if I change my mind later on, but it's going to be hard, it's going to be hard to leave him up there I think, because he could definitely be top of A no question, but S I don't know I think it suits him well, A is where you're going to start seeing a majority of the cast of fighters, this is where you got characters like Vegeta that are so good, Yamcha is definitely up here as well, and you could just fit in so many trunks, Gotenks, the Android 21, this isn't even in order by the way, maybe I move Gotenks back here, Goku, Blue, Zamasu, Cell is for sure up here, seeing Super Saiyan Vegeta below base Vegeta makes this really hard, but I think that's true, I honestly think that might be the case, or am I losing it, and the last character I'm going to put in A is probably going to be base Goku, he is last but I don't actually think he's last, it's insane how popular base Goku got after Wawa picked him up, just dominated, really showing some of the strengths of the character, yeah what else could he say, the spear bomb, super good for the damage, it's great of just a really good character, his assist is annoying as well, that stupid assist with the block stun and the two-way hit, oh god I hate base Goku, I hate base Goku, and B this is where you're going to see some of those lesser characters, but still very deadly in the hands of the right people, think 17, probably my number one pick followed by, oh what I didn't put 18 in A, let's go up there, but yeah B is like those characters you see when you see a main of them, you're like oh man that guy's gonna mix me up, but yeah so Ginyu, Android 21, I'd even put Hit down here, Hit could probably go up to A, I'll give you a loose A hit, I'll give you a loose A, I haven't seen a hit player in so long though, that has to be the order for me, so let's go through these all very quickly, Android 17 is super good, I love Android 17 in this game, but he does have his problems with just the stubby normals, one of his specials being almost completely useless, all that stuff, you've heard of his problems before and they're still there, but a good player can really make some moves happen with 17, so I like to keep him right up there with B, same goes for Beerus really, and Android 16 is probably the saddest character for me in B, the thing is you really don't see people playing him anymore, he's taken a lot of nerfs, he's not the king of fighters that he used to be, I don't know, I kind of hope he gets buffed at least a little again, maybe with some new tools or something, because I don't know it's sad seeing him down here in my opinion, I mean obviously you could probably push him up to A, I think he's more of a B now, I think he's more of that character that you just don't see enough these days, Ginyu is another one of those characters that could desperately use a buff, he's just kind of falling out of favor, even with the hidden low tier Ginyu mains that would like ruin your day, even there he's kind of falling out of favor, because people have just figured him out at a higher level, so Ginyu could definitely use some more tools, maybe a different way to call out the Ginyu Force or something like that, cycle through him, more combo potential, stuff like that, something to get the Ginyu mains back up and running again, TN just kind of too much of a basic character I guess to go any higher than A for me, the Dodon Ray assist is pretty nice, I'm not gonna lie, but he's just such a standard character, I mean again, if the game's so close you could kind of merge these two, or if you show me a decent player on nowadays, I could just, I can move them up, stuff like that, just like, I don't know, you need to see one in action, but I think B for these works pretty well, because you're always going to, you're never going to see them until just somebody that likes the character picks them up and starts mixing you, Majin Buu pretty much the epitome of that sentence, Majin Buu mains are wild, I cannot defend against this character, if it was a tier list on how bad the character beats me, Majin Buu would be S plus, it's not even a joke, the character ruins me, Frieza as well would probably be S plus if we were on that tier list, the keep away game, he's probably one of the more keep away focused characters in the game, along with DBZ Broly, but that's to be expected when he has those annoying Key Blast, the rocks, and the destructive discs that now give hard knockdown, Medell, that's just a sad character to see man, I wish Videl was stronger in this game, but it's just, it just wasn't meant to be, I guess, you need to give her some buffs, Arczos, make, give her something that'll get people experimenting with her again, so we could see her in more tournaments and stuff like that, and Napa is a character many considered to be C or I did, I'll probably put him down here, but I just really like what the character can do now, he's pretty annoying with the amount of lows, I'm not saying he's, he's high, I would actually put him last and be, because that's where I feel like he's belongs, he's got decent stuff, better stuff than these three, but still, he's only Napa, he's got to go at the bottom of B, and that about wraps of my tier list for season two of Dragon Ball Fighters, you can let me know your thoughts down below, honestly I could see myself changing the, A is the only one not ordered by the way, this is not in order at all, you could easily mix some of these around, and it wouldn't matter to me, but everything else I think I have down to an order here, yeah, I'm okay with this, I mean maybe B could be mixed up a little too, but we covered that in the video, like I said before, definitely let me know your thoughts down below in the comments, and make sure to hit the like button and subscribe if you enjoyed the stuff we make here, like I said, I'm hoping Dragon Ball Fighters receive some news about its future going forward, so definitely stick around to the channel to stay updated on all of that stuff, if you want to watch more videos right away there should be some up on your screen, so give those a watch, thank you again for making it to the end of this video, I have been Dr. Doya, and I will see you in the next one.


Hi everyone. So, I am going to talk about YouTube is again another developer experience enhancement tool on Kubernetes. So, how many of you have used Kubernetes here at Docker? How many have used Docker? So, this is only as the title says, it is about continuous deployment to Kubernetes using it. So, there is a lot of Docker Kubernetes stuff involved here. I hope everyone will be able to do both of this. So, a little bit about myself. So, I am Shahid. You can find me on Twitter. So, I am from this company called Hasuda. So, anyone heard of Hasuda before from the ground? Okay. Nice to see some hands. So, we work on Kubernetes, Docker, Postgres, GraphQL and some of the other trending latest new tech stuff out there right now, open source tech stuff. So, we recently open sourced our GraphQL engine on Postgres and that is the primary product that we offer. We also have a Kubernetes platform which is a more enterprise oriented product. So, you can find all of it on Twitter, go there and star it and it makes us really happy. So, I work at Hasuda, especially on the Kubernetes and Docker CLI stuff. So, any Heroku users here, people have used Heroku. So, Heroku introduced this concept of Git push. So, earlier what everyone was doing is they write code and test it at a clock early, test it at a clock early. And when they want to get it on the server, on the internet, what they had to do was somehow, I don't know, in a real race, I remember using FTP to copy files on the machine, but later people figured that they can just clone the reverse tree on the server, run some scripts over there and get it working. And then Heroku came in and introduced this new way of doing things, which is Git push. You had to just write the code and just do Heroku app create and then just do Heroku, Git push, Heroku master. So, what this Git push, it takes the language that your code is written in using something called buildpads, and then it employs it on Heroku. So, this was very eye-opening for developers. Now, they did not have to depend on, imagine the life of a front-end developer. The only thing the front-end developer cares about is my application is working in my browser. I know Java script, I know how to fix things. I don't need to care about SSH installing some stuff on that, and getting installed, I am installing whatever. I just need to get this application delivered to my users, and Heroku made that possible with just one Git push. So, now comes Kubernetes, or before that there is a tab Docker. Docker also introduced this way of doing things, packaging your application into a container, which can be a container. So, a developer only need to create a container by writing a profile, and then if they can put this container anywhere they want and get their code working. So, this was also a very good step for developers. Now, they only need to learn about whatever staff they have working on, and just keep it all a little bit Docker. So, if the Docker container can run out of their machine, they can just give it off to anybody who can then give it on to a server on the internet. Either using Kubernetes, a lot of the Docker swarm, a lot of the compoto. Then, Kubernetes came, and then it did. Now, developers write Docker file, write Kubernetes YAML files. Once they give it off to anybody else, they can just implement it. So, we thought, okay, this process can be easily, can be made a lot easier. As a developer, okay, you might need to know Docker, you might need to know a little bit about the Kubernetes YAML you want. But, if you want to get your changes immediately on a Kubernetes cluster, how can we, how do we get to from your laptop to Kubernetes in the fastest way possible? So, this is similar to a lot of constant and OpenShift introduced, but OpenShift is on top of Kubernetes, and it's a different, one more thing that you need to do. OpenShift is readily available on all the Kubernetes cloud providers right now. You can click two buttons and get an OpenShift cluster. So, this was the scenario before and after the interview, let's see. So, there are never three commands. You write code, you do a Docker build, then you do a Docker push to any registry. Then you use Qubectl command to edit the image, image link to the current image that you built. So, give you a change to simplify this process. And this is not just about three commands. You need to also think about how much time you need to take. So, if you're building a complex application and the Dockerfire contains several installation steps, what several difference is. Depending on infinite connection, all these build and push steps can take from anywhere, from few minutes to a few tens of minutes. So, if you have couple of GPs to the build and push and all, it will take a lot of time. So, we thought let's make this process a bit easier. What we need is to build the container. So, why don't we just build the container in the cluster itself, where the high speed element is guaranteed with the cloud provider. So, the way this is achieved is using githubes. So, how many of you used githubes earlier? Okay, great number. Very interesting probably. So, githubes lets you move certain actions to your key commands. So, pre-commit hooks are there, pre-push hooks are there, post-receiving, pre-receiving hooks are there. So, what you can do with githubes, githubes are very amazing. The common thing that I do is to add a pre-commit hook, which makes some reading and other kind of checks, before I commit any code whereupon. So, we make use of a hook, which is called post-receive. This is used to validate the code that you push to a remote before, after the code is received, after the objects are received, but before the tree is moved forward with that code, that object. So, I'll come back to this later. So, githubes combined with githubes gives you a lot of power. So, the demo codes were not in stereo. Let's see how that works out now. So, I have a short demo. I also have a recording available in case, but that's a new video. So, internet is in there. I don't know how it's going to work out. So, let's look at the demo. It's going to be on my display. So, this is the github repository. It's open source tool ready to go. So, contributions will come. Please go and start it. It just makes us feel better. So, you can install githubes on any Kubernetes cluster just by doing this kubectl create command. So, we have also made a CLI just to make this thing easier so that you don't need to do this YAML every time. So, I'm going to use the CLI right now, but CLI is not required. The whole value proposition here is that you don't need anything else other than githubes on your system. That's the whole value proposition. You don't need Docker on your local machine. You don't need kubectl on your local machine. All you need is githubes. So, I have the githubes CLI installed. I also have a Kubernetes cluster on GKE here. I realized this yesterday. So, my githubes is pointing to that. So, what I'm going to do is to do, this is in the front visible, should I do that? Okay. So, when I do githubes install, it's going to install certain components on the Kubernetes cluster. And it's going to ask you how do you want to expose to service. So, these are all Kubernetes cluster. So, I'm just going to say load balancer. Because this is GKE, it's the easiest way to move forward. So, while that is getting created, I have got also, there are many configurations available. If you will help you build your source code and deploy it, it will also apply certain Kubernetes elements for you. And it can also apply help chance. So, I'm going to show the monorepo example in which this manifest directory contains my condensing engine as deployment service object for Kubernetes. Microservice is there. It contains proper file. And an industrial HTML file. So, if you look at the industrial HTML, so there is some HTML here. Now, this is not a github pose. I'm going to initialize a github pose here. And I'm going to add all this and come in this github pose. So, this can be any github pose tree. Now, I'm going to github. So, this thing, you have it right. So, github makes use of something called Kubernetes Custom Resource Technicians. Many of you have heard of CRDs. So, it's something which will actually do this. Github, you can still get remotes. So, it's a no resource monorepo. So, to make github work, you need to write something called a github, a remote.yaml. And again, one more yaml to deal with. So, we thought let's make developers life easier. We have a constraint for that. githubremote create-yaml. You see the github file name. I'll use generate. So, it will help me create this remote.yaml file. I have to give all the man keypads of these questions. So, I'm going to skip Kubernetes Manifest. So, I'm going to give this. I'm not going to configure it of the registry right now. I'm just going to create this for this service. So, these are the Dockerfile path and we'll call this path for the Docker command. So, this creates monorepo, remote.yaml in this directory now. So, I have this yaml file available to me. So, now, what I'm going to do is githubcpl create this yaml file or a pressure method in the CLA also to create iphone monorepo, remote.yaml. So, the remote is created on the cluster and it's telling me this is the remote available. So, this can be obtained from the... if I do githubcpl create, I can get this from the remote object. For example, if I look at the yaml for this thing I can find the remote developer here also. So, I do githubremote and do this. So, now if I look at my githremote, there's a remote called example. Then all I need to do is I need to go into the Kubernetes cluster. So, this is the ip of the Kubernetes cluster which we can see from here. There is a githubt service available which has a public IP. Now, this IP... PUSHES are only possible with this IP using SSH key organization. So, if you look at this remote here, I have my SSH public here available here and only I can push to this remote.  So, all I need to do is githubcpl example master. So, now you can see the Kubernetes and SSR being applied. Deployment created, service created. And this is all coming from the Kubernetes cluster. So, if this is all the githremote responding to the client and Docker image is being built, you can see that Docker image is being built. And it's also saying that deployment service is built or not. So, if I look at the deployments now, I can see that WWW is coming. And if I look at the service now, I can see that it's still waiting for an instant IP but the service was available. So, what I did here is I created a Kubernetes deployment and service object. And I pushed my source code, built and Docker image is also going to roll down just with a key push. So, if you are used to the Kubernetes locker space, you would understand how this means your life is here. Because you would have executed 10 different commands till now and it would have taken a lot of time. So, let's look at the public IPs available. So, now if I go with this IP, oops, if I go with this IP, I can see the engineer's container is serving instant IP. Now, we have to go through a little bit of Kubernetes stuff here. The remote on YAMC had to be created, some githremote had to be set up. But once this is done, for every edit that you make, if you look at it or not, if I want to make some modifications to my HNX HTML, all I am going to do is, so let's say what I am going to do here is, I am going to remove this, I am going to add a githremote. So, all I am going to do is git, command, and then just push again. So, by doing this, the locker space being rebuilt and deployed on the cluster. And I did not execute it on the command, I did not execute anything to the command. I will go and refresh my page, still loading. Oops, did not work, I guess. Okay, this is going to happen. Jiffy is a bit lazy to load today. Anyway, so your code is changed now, you got the new files running in there.  We will come back and see that, edit these loads. So, going back to my presentation, let's talk a little bit about how this is going to work. Yeah, so, how this is going to work, let's talk a little bit about the architecture. So, when we did gitcube install, all it did was ds and Kubernetes objects. And one of them is this, yeah, is this Kubernetes controller. I will talk a little bit more about it later. So, then what happened is, you had your computer where you created a remote from there, and what happened is, it created a Kubernetes custom resource definition on the cluster, and the controller sees that a new work definition has been created. It creates a git remote control cluster, and now you can push to this git remote, and that will update the deployment or create the deployment, and also build an upper image and all of that. So, here we are achieving the local build using a git pre-receive group control cluster. These are all implementation details. If you are really interested in how gitcube works, then you need to worry about all these things. Otherwise, you don't need to care about any of this. You can just keep pushing your code of any Kubernetes cluster. So, the authentication, as I mentioned, is such keys. This also brings in a new pattern of doing things using Kubernetes operators and controllers. So, this is a custom resource definition that we saw. There is the API version, IIT and all you can see. This is a custom YAML that we created and Kubernetes supports this. So, there is access coverage using access keys, and you can just push your directly in any configuration. You just need to tell the gitcube controller where your local file is and where it should be in the local file. So, why should you use this? It's easier. Everybody knows git. You can just keep pushing things. Quick iteration time, again. You don't need to wait for the local and real local push to stuff to happen. Again, there is no complicated unbacked rules. You can restrict what gitcube can do on the cluster using unbacked. So, there will be organizations where organization is a problem. Your DevOps, and administrators can set up the gitcube for you and then provide access using simple authentication keys, just how git works. Now, it's a very small tool. It can be replaced with whatever you want later to move the production or whenever you want a more complicated file to start. So, the idea of doing things with git push can be extended to more DevOps tasks. So, you can modify this hook to do all sort of things you want. Gitcube doesn't do this at the moment, but it can easily fault you, edit the hook, and do all those things. So, this is an idea or an upcoming thing in the DevOps slash CIOps world where doing things using git is becoming very prominent. So, you can build and run unit tasks, deploy your code, deploy configuration, apply stateful migrations. All things can be done from gitcube. So, as I mentioned earlier, there's a new pattern of doing applications of Kubernetes, which is through this operator pattern. So, Kubernetes is the new kernel, okay, mentioned something like that. Kubernetes recorded people managing this course. So, Kubernetes is a new application platform. So, I wasn't aware earlier this year and if you know this, this founding team of Kubernetes, Craig McGluckey, Jorveda and Brandenburgs. So, I was at the top by Craig McGluckey and he was, he talked about how Kubernetes is a platform platform. It's a platform to build platforms. That's more like what Kubernetes is trying to achieve. It's giving you all these constructs with which you can build complex applications or complex platforms for your own use cases. So, the way to achieve this is to make use of Kubernetes primitives called custom resource definitions. So, you already have Kubernetes controllers doing things like deployments, services and stuff like that. Now you can define your own controllers watching on a custom resource definition called operators. And there are nice tools from CoreOS team which is now that had been called operator SDK. There is another thing called QBuilder. A lot of things which will help you achieve this pattern. Where along with the Kubernetes YAML, you will have your own application-specific YAMLs. And your own application-specific controllers is working constantly in the background to realize this YAML definition that you have to find by observing the parameters. This is a common way of doing things in the Kubernetes ecosystem. There is a controller looking at the currency in the cluster. It also knows what the desired state should be and it's doing actions to realize the desired state. This brings us to something called this can be a comparison can be drawn from a typical pipeline, a box pipeline and equivalence in the Kubernetes domain. So, building and running tests can be done in a log file. Multi-stage log file can do this very easily. Stateful tasks and all these things can be Kubernetes manifest. And then, if you have your own customers or definitions, you can do a lot of other extra stuff with it. And integration tests can be run with Kubernetes in containers, in jobs and all these things. So, this introduces a new paradigm called ETOPS and this is the definition of ETOPS given by the folks who point with the team and people. And where everything is will be declarative and version controlled. And you can go through this in detail later. So, you can have whatever can be described can be observed. And technically what is always done in it is whatever you can define in your kitchen can be automated and can be easily observable later. So, here is a, is ETOPS different from ETOPS or ETOPS is it a new thing? It's a way of going to ETOPS. It's not a replacement for ETOPS. We, we at Hasuna believe that CIOPS or ETOPS and the pipelines are way of doing the jobs. And ETOPS is declarative levels. If you look at a pipeline where you define certain steps to achieve a final state it's imperative. Your steps are getting different there. But ETOPS is you are only defining the final state and there are controllers working in the background to achieve the final state. So, defining the steps of the pipeline in a YAML file so that's a good thing that you need to do. So, these are the advantages of ETOPS declarative. You can go and control on it. You get a code review process on your configuration. You get monitoring with the current state and the desired state. But this also brings very clear developer and operations boundaries where developers only worry about the code and operators worry about how to deploy this onto cluster. And developers can deploy it using ETOPS to the cluster. So, but there are challenges to be solved yet. You cannot put everything in an interrupt or secrets other than the requirements are there. New tools are required to achieve certain things which have been traditionally done in Indonesia. But these problems are getting solved and a lot of companies are working towards achieving this in Indonesia. So, that's my talk. Thanks for listening. I have couple of minutes for questions. So, if you have any questions feel free to ask. Otherwise just go check it out, get to you, contributions are welcome in us on this order, when it is like wherever yeah, start the report any questions? Pardon? I think our continuation is done using SSS publicities. So, if you want your administrator or yourself can create a phone. Whoever is a cluster administrator can create a phone. And you can say that only this SSH keys are allowed to be used. So, this will help you to do a very easy user management. Which is to add a SSH key to the IPv5. So, that's how you do the management. So, if you have to push a development branch A on your local you have to look at push remote name, your branch name called master. This will push your branch to the master of remote. So, that every push will result in a deployment process. So, if you push 10 comments together in a single push all these 10 comments are taken together and a new docker image is built and with that latest comment. And then deployed as a new Kubernetes product. So, you can achieve 0.10 rollouts and all using this same unit. So, you can update you can say which deployment you want to update, which container in that deployment you want to update for any push to this input. So, all these are configurable into the other product. Yeah, any other questions? So, right now the way it works is so, the question was about provisioning does it also consider provisioning in your account? No, because the way it is designed you will see that as a developer tool in your development cases. So, wherever you want the application to run you would install the cube there itself. So, it will update same cluster. So, it is in the same cluster it will not contact a different cluster in the current state, but you can in your case also you can always achieve a lot of things. Ok, thank you thanks a lot you can find me here. I have some old hostila stickers. So, right here on the graph. Thanks a lot. Thanks a lot. In minutes of our tea break tea is served on the 8th floor and in between you can visit the exhibition area it is in the page of the central ground. So, we have a


Gentlemen, welcome. How are you doing? Good. Introduce yourselves. Tell us who you are and where you are from. Stig, take it away. Hi. I am Stig Telfer. I'm working with Cambridge University. I'm just an open-stack HPC contributor there. So my background is in HPC and going back through supercomputing and scientific research, but also a little bit in how we can do that with open-stack. So that's what brings me here. Very cool. Blair. So I'm Blair Beth White. I'm a HPC consultant at Monash University. We run our HPC on open-stack at Monash. And so that's why I'm here. Well, cool. We're definitely going to talk a little bit today about high-performance computing. You both mentioned it and why it's cool and what you can do with it on top of open-stack. But before we get into it, let's go into an example. Stig, you were talking a little bit about how you first got involved with HPC about potatoes of all things and the beauty of potatoes. Why is potatoes relevant to high-performance computing? It's a good example because it says that science and scientific compute, you don't really have to put it into a box. And I was working on a machine which was, it was a deep learning neural network algorithm machine and it was using image processing to identify beautiful potatoes from ugly potatoes so that a supermarket could take them and they could pack them according to premium or economy. It was HPC. It had 28 processors in it. It was, I don't know how many gigaflots just to process those images, but it was an HPC application which didn't involve physics or science in any great data. Absolutely brilliant. So you've already hit on the core principle here. You said, you know, it took 28 instances, right? So high-performance computing, what are we talking about? Give it to me in layman terms like how would you tell your mom about or your dad about actually what HPC is? I think HPC is really anything that you can't do with your workstation or your laptop. You need a bigger machine. That's sort of the base definition. Other people branch off into many and specialized areas and divide it up into high-throughput computing, high-performance computing with tightly coupled networks are required, that sort of thing. But really, you know, you can make it quite a broad church, I think. There's definitely an intensive component to high-performance computing in whichever form it takes, so I guess that it is computing that is stretching the limits of the system that you're running on to get the most out of it. Very cool. So talk to me. How big are we talking with HP? So we got Monash and Cambridge University. Obviously, this is something that scientists really care about, you know, being able to do their work on, whether it's from beautiful potatoes or I know you guys have chatted with NASA recently. What's happening at Monash and Cambridge, which is cool. First, give me the size of how big are we talking here? How many servers are we talking about when you actually are talking about your HPC instance on OpenStack? It's hard to say at Cambridge, actually. We have a number of systems, and I've never actually rolled them all into one ball, but I think that's what we are going to be doing fairly soon. Are we talking hundreds or thousands of computers here to the average person? Well, one of the systems that we have is called Wilkes. It was the number two system in the green 500 of the world's energy efficient supercomputers. So it's a big system. It gets there through using a lot of GPU power. That machine is, I forget how many nodes, but it is a couple of aisles in the data centre. So it's a big machine. We also do a lot of work with high-performance data analytics, and those systems are equally big. I mean, we have a million-pound machines at a time. So lots of money and very serious stuff, because obviously science is based on it. Blair, what about you? What at Monash? What are we looking at? So I think maybe a little bit smaller, but I'm managed by OpenStack at the moment we have maybe about 7,000 cores in total. The biggest single logical entity there is a new HPC cluster that we're just at the tail end of commissioning at the moment called Massive 3. And that machine is maybe a little bit interesting because it has a whole pile of GPGPU as well in it. And so that actually makes up probably the bulk of the computational muscle in that machine. So walk me through a little bit of the differences between, and I'm going to say this wrongly, but the old HPC of doing things, the grid-based systems, and it has a very long history. It goes all the way back into physics and the way that they do their experiments. And now we've kind of got this new HPC on the cloud thing. What's different? What's new about HPC on the cloud? Flexibility is one of the key things. So when you're supporting a diverse population of users, OpenStack enables you to bring together a lot of different requirements into a single system. And for research computing, if we were buying individual machines on a rack-by-rack basis for a project and then another project and not really sharing the resource, we lose out. We don't get the utilization that we could do if we were to build it all into a private cloud and then manage it using the software-defined infrastructure that OpenStack provides. That's what it does for us. Love it. Flexibility. Fantastic. Anything else? Yeah, I mean, I think the other thing that it does is it can lift your HPC operations if you're going to actually run a managed HPC service atop of OpenStack. Then it lifts that up into the new world of DevOps and continuous integration and so forth and deployment, which I think is actually that's a really powerful thing and it's very useful in the HPC community, which is previously run with quite static environments, very little change, but can no longer go on doing that in the face of, particularly over the last couple of years, was in a whole pile of big security issues where it's no longer viable to keep just stay on the old kernel just because that's what we run on this system. It sounds, HPC has this very technologically advanced image about it, but the system management is really very static, as you say. It hasn't really evolved in a massive way since whenever. Yeah, in HPC, traditionally, the system management configuration is actually pretty much 95% in deployment of the node. So cool. What I think is exciting about this is since we're on SuperUserTV, I guess it really boils down to actually how you're helping the researchers and scientists do their research better. So as a bit of a game and a bit of fun, I'm hoping each of you can actually ask some questions of one another about your users and kind of what they're doing on it. So take a minute, take a minute if we can always do a cut here and then come back to it, but ask each other a couple of questions on these topics. Okay, oh well. Shake it up. We have everything, I guess, you know, because it's sort of like they're a typical campus HPC resource where you've got users, users on the one hand have some MATLAB code that is taking a long time to do on their desktop or suddenly they want to do it 10,000 times for a parameter sweep or something like this and, you know, so they then need to scale that out on a cluster or just even on other distributed resources. That's probably, that's kind of actually the most common use case and then there's other people that are actually doing MPI or OpenMP type parallel programming, others that are doing visualization, instrument data processing. We've got the lot really. The list goes on and on. Quite a few users on your cloud as well. How many users are there on average in the Australia National Cloud? Well, so we run our infrastructure as part of the Nectar Research Cloud in Australia which is a bit of a pioneering project. It started up in 2012 running OpenStack. Almost 10 data centers, right? Yeah, there's eight nodes actually. Eight nodes, got it, yeah. And so at any given month on the Monash node of the Nectar Research Cloud we have about 350 active projects on that. And at the moment in broadly speaking in Nectar there's over, I think there's about 1,200 active projects on that Research Cloud. Fantastic. We have a very interesting project in bioinformatics, which I was just thinking about, which I'm looking at how we can bring that into an OpenStack environment in a way which is as performance as possible. Looking at how we can do a kind of a genomics workload in using the latest or the best of the modern tools is something that's of a huge interest within our group in Cambridge. So that's something that I'm going to be focusing on with the team there. I'm really looking forward to that talk tomorrow actually. I think that's something that we're very interested into. Brilliant. And so if people, obviously for the people who aren't here, what's the best way for people to get involved, especially with HPC and the scientific community? Well we've just, within the foundation, we've just created the scientific working group. And the working group is not necessarily a direct bond of contact, but it's an advocacy for how we can actually help scientists, researchers who are looking at using OpenStack, looking at bringing OpenStack into their installations. And it's really about how we can share information, how we can bring people together and exchange ideas about the best ways of doing scientific compute in all its varied forms in an OpenStack environment. We're trying to give some structure to the hallway conversations that we invariably have at every summit with more and more people starting to become very interested in moving their scientific compute or HPC onto OpenStack or somehow leveraging OpenStack alongside those other resources. Fantastic. So it's as easy as going to Google and typing in scientific-wg for the scientific working group. Throw an OpenStack there if you're wanting to find it on Google. Thank you both so much for coming to the conference and thank you for putting forth your time to make this community initiative happen. Obviously OpenStack cannot do these things unless good people like yourselves actually bring people together under a common umbrella and actually try to change the world for the better. That brings me to an interesting final point perhaps in that Nectar was quite pioneering back in 2012 going out and deploying OpenStack as a community cloud to the research sector in Australia and it was the community model in OpenStack that really made us make that choice.  I was fortunate to be one of those people and it was really not about any particular technology thing. It was about the community and the open source model around it. Absolutely. Fantastic. And it was a really great choice. Thank you both so much. We'll see you around the conference showroom. Excellent.


Welcome to your first last session today. So I'm happy to see so many of us together for separations. We have two talks on proving what we cannot prove in cryptography, and the first talk is on powers of hierarchical identity-based encryption, and it's a joint work with Mohammed Mahmoudi and Amir Mohammed, and Amir is going to give the talk. Okay. Thank you for your other introduction. My name is Amir Mohammed, and I'll be talking about limits on the power of hierarchical identity-based encryption. This is a joint work with my advisor, Mohammed Mahmoudi. So an important goal in cryptography that we'd like to study is what are the limitations of P that is what primitive P can or cannot give us, and what is the complexity of P? What are the assumptions that we need to assume or the primitives that suffice to give us primitive P? And in our work, we prove one such limitation for HIV-E, which is hierarchical identity-based encryption. Specifically, we show that HIV-E does not give us collision resistant hash functions in a black box way. And to our knowledge, this is the first limitation result regarding the black box use of HIV-E. And at first glance, this may seem like quite a... It's not immediately clear why we started such a question. And it might not be such a natural way to get collision resistant hash function. But the color is that we get from this assumption, from this result, are quite impactful. So HIV gives us implies primitives such as CCA2, public key encryption, and collision resistant hash function is also implied by other primitives, such as fully homomorph encryption and private information retrieval. And our result shows that anything on the left side does not imply anything on the right side in a black box way. And so the previous results that are related to ours is... First, we have Simon 98, which shows that one way permutations doesn't give us collision resistant hash functions. And then we have the work of Heitner, Hodge, Reingold and Segev, that show that trapdoor permutations doesn't give us collision resistant hash functions. And the final work, the recent one is by Ashraf and Segev, which show that IO plus one refunction doesn't give us collision resistant hash functions. We will rely on and extend the techniques of the first two results. And as for the last result, it is quite significant to us, because the result combined with Waters result, which shows that we can get functional encryption from IO, provides an alternative proof to a corollary of our main theorem, namely that identity-based encryption does not give us collision resistant hash function in a black box way, but it doesn't say anything about hierarchical identity-based encryption, which our work covers. And so the plan of this talk is I'm going to first define what is hierarchical identity-based encryption, and then I'll just say what are black box constructions, what are black box separations, and then I'll just talk about our main result and talk about the main ideas and how to prove this. So identity-based encryption was introduced by Shamir in 1984, and it's not until 17 years later that we had the first candidate construction from bilinear maps by Bonet and Franklin. And I'll describe how identity-based encryption works using this scenario. So let's say we have a company with a manager, and the manager has a massive secret key and a corresponding master public key. He would distribute and publish the massive public key to everyone. And suppose we have an external user, Alice, who wants to communicate with one of the company employees, Bob, and so she would use an identity-based encryption scheme to encrypt the message with respect to Bob's public identity, in this case it would be his name. And when Bob wants to decrypt this ciphertext, he would request a secret key from a manager, and the manager would give him a secret key specifically for this employee, for Bob, and so this allows Bob to decrypt the ciphertext and obtain the message. Note that there is different than normal public key encryption, and that Bob does not publish some kind of public key that allows Alice to encrypt. Alice only needs to know Bob's public identity, his name, his email address, whatever is public, and she would encrypt it with respect to that identity. And a natural extension of that would be hierarchical identity-based encryption, where we have a higher entity, a higher player. Say we have a CEO that now generates secret keys from managers, and that allows the managers to use these secret keys and generate secret keys for the employees that are under them, and they can only do that for the employees that are under them. And then Alice and Bob can communicate as before. So in defining the security of identity-based encryption, we have to consider the following scenarios. Suppose we have two employees who decide to collude with each other and combine their keys in an attempt to recover the message from a ciphertext that was intended to their colleagues, Dave. And when we define security, we should be able to say that even with such collusion, we should not be able to recover the message that was intended for another recipient. And more firmly, the security is defined using a security game between an adversary and a challenger for giving the master public key. The adversary can request secret keys for identities of his choice. This models collusion. And then once he does that, he can adaptively choose the idea that it wants to be challenged on. Then the challenger would send an encryption of a message, either zero or one, using the identity that was selected by the adversary and the adversary to win the game is supposed to guess which bit was challenged, which bit was encrypted. So now I'll talk about black box instructions and separations. So when trying to study the limitations of a primitive, we have to define the framework under which we explore this limitation. And the most widely used model is the fully black box construction model, because this captures most of the efficient and desirable crypto-primitives. And so here's how we'll define it. This was introduced by Imbagliaz-Rudich and later formalized by Rheingold, Trevisan and Vatan.  And for any adversary A that breaks primitive Q, we can create an efficient adversary R that uses A in a black box way to break the underlying primitive P. And it is easy to ascertain that such construction is relativized. This means that for any oracle, if P exists relative to this oracle, then Q would exist as well relative to this oracle. So one way of ruling out such a black box construction is to show an oracle relative to which P exists, but Q does not. And that is one way of how to show what we call a black box separation. So again, the black box separations, in the way we define black box separations usually and in our work, we're going to show two oracles, the P provider oracle, which facilitates the secure instantiation of primitive P and the Q breaker oracle, which allows us to break Q. And together we call this the separation oracle. And since this is a relativized oracle, a relativized world, we allow P and Q to call the separation oracle. We're going to use B, the Q breaker to break Q, and the P provider to instantiate a secure P. And we should make sure that when we add this Q breaker oracle, we wouldn't break P in the process. That's one of the things you have to make sure of. And so in our work, our P provider is a randomized HIV oracle, which I'll define later on. And we want to show that HIV exists relative to this oracle, but collision-resistant hash functions do not. And the collision-resistant hash function we will be using is what we call a SAM oracle, which I will talk about later. It's the same oracle that was defined by Simon to break the collision-resistant hash functions. So our task is two-fold. First, we're going to show that collision-resistant hash function can be broken relative to this oracle. And second, we have to show that HIV exists relative to this oracle even after we add the SAM oracle that breaks the collision-resistant hash functions. Okay, so here we go. So first, let's rule out collision-resistant hash function. We have an oracle called SAM, and our goal is to show a polyquery attacker that can break hash functions. So what does an adversary do? Adversary simply asks a query to SAM with the circuit of the hash function as input. And what does SAM do? SAM is an oracle that takes an output-compressing circuit and outputs a pair of colliding inputs where each input is uniformly distributed. This immediately gives us a way to break the hash function, and that simply breaks the hash function. So that's an easy way. That's the easy part. So the hard part is to show that whether the security of HIV is now compromised because we added such a very powerful oracle to our separation result. So normally, when we want to prove that something that primitive exists, we usually use techniques such as lazy evaluation, such as in the work of Implugliaz Rudich, but it will not work here because we need SAM to be dependent on this RHIB oracle. And here, since it does depend on it, we cannot use lazy evaluation. And so we need to use something else called the compression technique, which I will explain. And so next step is we have to show that... So now we ruled out collision-resistant hash function. Next step is to show that HIV exists, and we're going to do that using what we call a compression technique. And for simplicity of this talk, I'm only going to do it for IBE, our proof extends to hierarchical, but the main ideas will show up here as well. So in building an IBE from RHIB, the randomized IBE oracle, this is similar to the way that we get public encryption from random trap-to-permutation. Instead of having two permutations in the trap-to-permutation oracle, now we have three permutations. So we added this new permutation that allows us to generate keys for any given identity. So this provides an index into gen, and gen provides an index into encryption. So this allows us, for example, to implement the setup algorithm of the IBE by simply running setup on the master secret key and allows us to generate the keys using the key gen, using the middle layer, and allows us to encrypt and decrypt using the last layer. And this is how we build an IBE using this ideal oracle. Now what concerns us more is the security of IBE. And how can we improve the security of such a scheme? In particular, an adversary that has a master public key chooses an identity and then receives an encryption of a challenge that is supposed to invert the challenge and find x star. And it can do so by calling, using calls to our IBE, the randomized IBE oracle. And we proved that using compression technique. This compression technique was introduced by Janar and Travesan in the context of proving crypto-permitives. And at a high level, what this does is suppose we have a permutation that is represented this way, using some number of bits. And suppose you have an adversary that can break this permutation somehow. It could invert this permutation, like, for example, suppose that it could invert some number of points in the permutation. Now the compression technique says there are two algorithms. There is an encoder that depends on the adversary and outputs a compressed version of pi and a decoder that also depends on the adversary but reconstructs the original permutation. If we can show that such encoder and decoder exist, then we can show that only a few number of permutations are good for the adversary. And by good means, if an adversary could compress this permutation there are only a few number which it can invert, which it can break. And since there are only a few number of such permutations, we can say that random permutations are hard. Because when we draw them at random, there are only a few that are good for the adversary. And so if you want to demonstrate this using an abstract example for the case of random permutations, suppose you have a random permutation here where each point, each black point is a point in the permutation. And suppose we have an adversary that inverts these permutations, then we only need to explicitly represent these points because we could use A to recover to invert the other points. So look at how much we compressed this permutation. We now need only to represent a small number of points and we could use the adversary to invert the rest. So we compressed the permutation by a lot. And this shows that we can represent the permutation using a small number of bits. Therefore, only a small number of permutations are good for the adversary. And we can do the same thing for random chapter permutations. We could say that if an adversary that accepts a public key and a challenge, fpk of x star, and is supposed to invert the challenge and get x star, it can do so using one of two ways. It can either recover the secret key and using the secret key, it could then invert, it could do f inverse and find x star. That's one way to do it. But if it does that, it means that we could compress g. And this g is a random permutation that reduces to the case of inverting random permutations. The other case, it finds x star without finding sk, the secret key. That means without finding the secret key, it's just going to look at fpk x star and it covers x star somehow. But that means we can compress this permutation, the fpk permutation. And since fpk is a random permutation on its own, we can reduce this also to the case of inverting one way permutation. And now we have to make sure, recall that, we have to make sure that by adding Sam, we don't break anything. So the good thing is here that even if we give a, the Sam oracle, the powerful oracle, the work of Heidner et al. show that they can turn this adversary into another adversary, b, that makes slightly more queries, but the Sam oracle won't interfere with our compression technique. This means the Sam oracle won't be helpful in providing us with a way to break hiebe. We can still do the compression lemma and it will still work. So we can, that's what they show. And so we come to our original question, which is how can we show a compression technique for our oracle, this RIBE oracle? We want something that, we want something that is the same manner as what we did for random permutations and random trapdoor permutations. Specifically, we want to show that if an adversary can break this RIBE, then there are only a small number of oracles that it can do so. And if you would recall, the problem with IBE adaptive security or the issue here is that the adversary could issue inversion queries to the challenger. It could ask the challenger to supply him with secret keys of identities of his choice. And the second issue is that the adversary chooses the challenger identity. These two issues weren't present in the random permutation or trapdoor permutation games. And so this is the new issue that we handle here and we provide the new compression lemma that handles these two cases. So for the first issue, the adversary can ask inversion queries. So we can also think about this issue in the context of random permutations. That is, the adversary could also ask inverse queries to the permutation. So this new thing here is pi inverse. This is the new oracle that A has access to. So let's say that these are the points, the red points, that A could ask the inverse of. So we can't say anymore that these points are being inverted by A because A is asking the permutation to invert it forward. So we can't say that these are points on which A can invert. So we have to pull them out of the set of points that A could invert and explicitly represent them. So now we're going to pull out these red points from the set of points that A claims to be good at and we remove them and put them here so that we explicitly represent them because A is not good at them anymore. But we still show that even after doing that we can still do a good enough compression to show that A can only do well on a small number of oracles. And this is for random permutation. We could do the same thing for our case, for the RIB oracle, except here the adversary can ask inversion queries from the middle layer gen. And so we could say that if the adversary could ask inversion queries from this layer, then we could still be able to compress this and by compressing it there are only a small number of RIB oracles that the adversary could break. And for the second issue, the adversary is choosing the ID star. So this means that since it's choosing the ID star, we can't or we do not know of any way to compress this oracle if we allow gen, the middle layer, to be a permutation. However, we show a way to do though, we show a way to compress the oracle if gen is made to be an injective function instead with a very large output. If we allow it to do that, then we can show how to compress this oracle by a constant number of bits. However, a constant number of bits is not enough to show a good compression. I mean, even if we show a constant number of bits, a compression, the adversary will still be able to break the oracle with a constant number. The probability is not enough, so we have to show something better. So we use the fact that it can invert, that A could invert this function for an exponential number of master public keys, and therefore we have an exponential number of bits that we can compress. So the main idea here is that we change from using permutations to using trapdoor injective functions and that A could invert for an exponential number of master public keys. So putting things together, now we have an oracle SAM that breaks collision-resistant hash function. We have an oracle, our IBE, that gives us H-I-B-E, and we ruled out collision-resistant hash functions using SAM, and we proved that H-I-B-E exists using our enhanced compression limo, or enhanced means that we deal with adaptive adversaries as opposed to the normal random permutation game, and even if we include SAM, we can use the same techniques by Heitner et al to show that even with SAM, H-I-B-E is still secure, and the same techniques apply here. So the open question here is that we have... we're still looking for more applications of the compression amplification techniques that we developed here for adaptive adversaries, and, for example, here we're handling non-uniform proofs of security, and we'd like to discover alternative ways of getting this separation. For example, we have... we want something similar to what Asharov and Segev did by showing that... we want to show that IO doesn't give us adaptive H-I-B-E. Note that the recent result of Berkersky and Segev show that FE does not give... gives us semi-adaptive H-I-B-E. So if we get... if we have a result that shows that FE gives us fully adaptive H-I-B-E, then it extends our result. And finally, we want to see if there are any extensions to non-blackbox reductions similar to what Pass et al did for proving the... when we're permutating something, it does not give us collisions just hash functions in a blackbox way. Oh, yeah. Thank you. Some time for questions. I have a question. So the AS paper, that rules out non-blackbox reductions. Is that correct? Which one? The AS 15 paper that you mentioned at the end. Rules out non-blackbox? Non-blackbox constructions of collision resistant hash functions from... I don't believe so. Does it? But is it at the case that if you're using obfuscation, you have to assume that the... you have access to the code of the construction? Yes, but they do so with respect to I... I mean, the oracle that they use is I1, one-way function altogether in one box. Okay. So I don't think they... the oracle that they use, the separation oracle, allows it to use one-way functions in non-blackbox way, but it is in itself blackbox. So both impossibilities are also fully backwards? Okay. So let's thank Amir again.


What is going on guys welcome back to the channel and I do appreciate you being here today I am back with another destiny community highlights video and guys if you have any amazing clip You'd like to share with the world send it into the email address linked at the top of the video the Sturbs and if you enjoyed the video leaving like really does help out and if you are new around here Enjoy daily destiny to videos be sure to subscribe but guys. I hope you enjoyed the video and hopefully I will see you on that next one You make this look easy nor can the power created by this experiment Ashes learned the same lesson that gold did We cannot create or take light Only the traveler can choose to gift us with it Let us know if we can help with anything else.  I've got your turn one wish grab deserves another don't advantage is yours Zone a captured zone seed lost take out those Longer route, but we cannot guarantee safe passage