All right, we can get started. Hi, my name is Callie Dolphy, and I'm a data scientist in Red Hat's Ospo. Sean Gaggins, I'm a co-maintainer of the Augur project and a member of Chaos. Yes, and this presentation is gonna be about a metrics models with the robust hardware software of 8nought and Augur. This is honestly kind of like a celebratory presentation for us, we've been working probably like over a year now on trying to get a functional environment where both of these projects work together and it's honestly made both of the projects better through this, so yeah. And so we're coming in here with the whole, this was something that Sean had brought in from kind of the overall thesis of today and looking at the state of Chaos and how to implement the metrics, not just coming up with what the metrics were. And that's honestly where we started working together of I was coming in from a data science perspective of trying to see how could I get access to structured data to be able to do the data analysis using the Python packages and other environments that were native to education with data science and he brought in that structured data. And so that transitions well. So we look at Augur as a path to data science and really if you wanna think about what Augur is, it's long had a really crappy interface but does data engineering really well? It's long had a crappy interface and does data engineering really well? So you end up with mountains of data and we've spent nearly six years working through all of the anomalies that occur when you're mining open source software data. We're talking about weird character sets included in messages, everything that can possibly go wrong with data goes wrong with data in open source routinely and so we've spent six years working on that and putting the data into a structured relational database and then validating it against platform metadata. And the result is that we have data that we think we can trust, that we have a high degree of confidence that we've worked out all the bugs and we have a way of identifying the new ones as they occur because believe it or not data anomalies don't stop. You never find them all, there's always new ones. Somebody is always inventing a better problem. And one of the key things we've done in the last year working with Callie and James who's also here is scale up Augur. So previously Augur was pretty slow and we've introduced a queuing architecture where we can literally make hundreds of requests at once and instead of taking two weeks to populate a thousand repos, we can do that in about two hours now and so over the last six months we've created an Augur instance that has over a hundred thousand repos in it with all of the data that you can imagine you might want about a repo. So if you think about what that means you need large scale data for insight. So if you ask ChatGPT the question please write me an essay about Canada. Thanks. What makes the result stunning? Why is ChatGPT, for example, so cool? Is it the algorithm? Have we advanced our machine learning algorithms that much? Or is it that we've created really good training data sets? And so one of the things that we've done with Augur is by gathering data from the scientific, academic, corporate, non-profit, non-government organization spheres we've created data sets that are garden to focus on what we know about open source projects in each of those spheres. And so in doing so we leverage hundreds of thousands of messages or millions of messages garden by the domain so that we can compare the communication that occurs in a repo against all of these different domains distinctly. And now I'm gonna pass it back to Kali. Yep and this is where Project Aspen comes in this is looking at it from the data science perspective. And when we're looking at how Augur fits into this that's those first few phases of what you would call like the data science workflow. If you need to collect the data, you need to clean the data, it needs to be structured for you to actually be able to do that analysis and try it in true that is where so much of the time and effort goes from. So having that accessible has made us be able to build this project which has two components and eight not which is the one that we'll be talking about mainly today. This is a cloud native container deployment strategy and it uses the Augur database and it has the validated back in data and it allows all of the data scientists or other data enthusiasts folks to use a Python native data science tool chain. So if you're using pandas, if you're using any type of modeling, those can be now used into making these visualizations and connects to the data easily. And this is a good point where I'd wanna shout out James Kongstall who is the reason why this like cloud container platform is so functional and has gotten us to where we are today with that. And the second portion of it is the repel portion of the project and this is the open research side. And our current focus right now is on the developer social network analysis of open source ecosystems. And if you wanna talk to somebody about that on Drilla's here as well and she's been doing a lot of work on the repel side of the project. So when we're looking at how Augur and 8knot connect the like how we were going through before Augur is our back end of the 8knot dashboard and we're able to compartmentalize the different processes of the project. So then the data engineering is in one place we have the all of the software engineering and making it to where we have all of the workers that get that data into populated visualizations is all compartmentalized. So then the data scientists themselves only have to worry about doing the visualizations and all of this works for any combination of repositories as well as allowing for user inputs. We've been focusing a lot lately in chaos around metrics models and I wanted to make the brief point that we have the data available for all of these metrics models with an Augur but whereas grimoire lab has built over 70 dashboards and sigils we have four. So we have an opportunity with the data to start building out more of these metrics models within 8knot and Kali am I doing the demo right? Okay, Sean doesn't know how to operate a computer. Is it here? Yeah, I want to try to switch to the browser. Sorry. Oh yeah, computers are very difficult. Especially the latest Mac upgrade has made switching monitors difficult. If any of you have a Mac, you know what kind of pain they've instilled with their new upgrade. So now it's like that. Okay, so this is just one of the dashboards. It's the overview dashboard for a series of projects in 8knot and it's the ARM embed which is a real-time operating system. And let's say that I want to gather new data. Let's say that I want to get data. I click the Augur login signup button and I create a user just like this. I'm gonna put the mic down and here you're prompted to just give Augur permissions and you'll click your little authorized button and it'll take you right back to 8knot. And once I'm in 8knot, it'll take a little bit of a minute to refresh here. And once I'm here and there's some navigation things we need to work on, but if I click Sean, I will get back to my profile and I can click repo tracker. And if I click repo tracker, I can actually create a new group name. Like for example, let's create a group name called Microsoft. And I've added the name to Microsoft GitHub organizations and I am gonna put them in the Microsoft group. I'm gonna add them and this will take a minute because these are very large repositories. And so while that's happening, I'm just gonna go back over to 8knot. So what's happening in the background there is we're making a series of GitHub API calls. If the repositories that I'm adding as my new user already exist in the database, I will automatically instantly see that data. If the repositories are new, it will take between two hours and two days depending on the size. And I think Microsoft has tens of thousands of repos. So perhaps it'll take a week, but all of that data will eventually be added. And then the next person that comes along and creates a user and adds Microsoft as an organization will be able to see that data instantly. And so obviously we're gonna work on tightening this integration, but the idea is that everybody who wants to see data, if it's already gathered, they don't have to wait. And so whatever data you wanna see, you don't have to wait. Anything you'd like to add? No, we can transition over to more of the visualization side of things. Nobody in New York saw it, did you? Oh no, I can do it from here. Oh no, you have a few, the new. Oh yeah, okay, so we've talked a lot about metrics models. Where metrics models come from are OSPOs have analysis that they use. And so all the metrics models that exist inside of KS, and there are 10 that are released right now, have emerged from OSPOs who have collections of metrics that they wanna see together. And so these are eight, what I would characterize as new metrics models that what we'd like to do is create them as formal metrics models inside of KS because they already exist in the eight-knot tool. And like existing metrics models, they're driven directly by OSPOs needs. And you can see there's lots of little OSPOs in the world. And many OSPOs enumerable needs and they evolve. So there are new metrics models forever. There is no end to the metrics models just as though it's turtles all the way down. It's metrics models all the way down. These are a listing of the metrics models that exist in eight-knot already. And you can see that we've created issues for each of them. So we pointed those issues at each of the metrics models that already exist in KS and made a list of making them inside of eight-knot. So this is one way that any tool I think can help to implement the metrics models that already exist, create an issue, get somebody to work on it. Yeah, that definitely describes pretty well like one side of what contributions are for the eight-knot project. Contribution can be in the form of coming in with an idea of a well thought out metric or visualization. People love to focus in on the technical side of things. And as someone who's made a lot of the visualizations that are on eight-knot, the time and energy that needs to be spent into the actual idea and the methodology around the metric is a lot more than the hour or two that it takes to actually implement it in the Dash Plotly platform, which I don't know if I've mentioned that yet, is actually the tool base that we're using to build our dashboard. And so I wanted to hop over a little bit to some of the different visualizations and kind of two different things that we've started to really focus on. And one side of it is taking a lot of the more well-known metrics or visualizations and taking it a step farther to be able to allow for more insights. One of the ones that's become a really popular use has been the contributor growth by engagement. This is one where you can start to look at and you can choose for whatever community that you're looking at, what time you would describe as a contributor being drifting away from a community or away from the community. And you can start to see a little bit more into, and this we can, I can just zoom in a little bit. You can start to see how, what is the consistency around your active, drifting and away contributor base? Your away is always going to grow bigger. There's always going to be more and more contributors total over time. But we found a lot of insights to being able to come of the variants that is in that away and drifting. So this was kind of one to again, exemplify taking a very commonly used visualization of contributor growth over time and adding a new dimension of it that we're easily able to do because of the Python tooling and being able to use things like pandas and dash plotly. And another angle that we were starting to look at is there's different questions that you are not able to answer directly. I know probably everybody in this room has been able, has been asked, okay, what is the exact company breakdown within this project? And that is a question that I don't think is really capable of being answered directly in a general case. And so the idea, another idea we've gone about doing is how to look at the same question from multiple different perspectives. And so each of these visualizations, they look at the company affiliation or looking at specifically at domains from a different view and each one of them are going to have strengths and something that it shows well and some of them that doesn't show the whole picture. And so hopefully to be able to have from a different, a whole set of visualizations around the same question that you can actually get a holistic view and be able to answer that question as well as possible. And so, and we can, yeah. One point I would make is we can't tell you the company because we don't have that information only the company knows who works for them and what their email is. So unless you're using your company email domain we can't determine that. However, anybody who would deploy this toolkit has a list of the employees and their emails and their GitHub IDs and could break this down further with their own custom dashboards if you have that information, which we don't. Yeah, and that's one of the great things about 8.9 but we hope this is being used for is that this is we're not going to produce any visualization that has individual identifiable data. But if you have a specific company or project need where you would like to do that you can easily fork this project and make those visualizations that take in that individual and very specific data around your projects and it's all set up and templated well to make it where that effort around that is much smaller. And so let's go back to here. Oh, that was a call to action. But one thing I wanted to example, look into is actually what a contribution looks like from a visualization standpoint and how the compartmentalization of the app goes into looking at it. But we, I think we're getting up on time and luckily we've kind of covered most of it. So, yes. All right, thank you everybody. How are you going? How are you? Well, thank you for, well, first time I did a, I've done a long trip for a while after pandemic. So, yeah, nice meeting you, seeing you all in person. Yeah, so, well, so thank you for the presentation and all of this, so it's been great. Now we change to the other piece of software that we have in Chaos, which is Grimoire Lab. So it's been quite interesting because the last time I went to one of the Chaos Con was in Dublin. So that is September of last year. Back there we didn't talk to speakers but we were all discussing about collaboration. Today it happens that we are all talking about ecosystem. I don't know why, but my talk is about ecosystems as well. So some quick updates on Grimoire Lab. So we are now fully supporting OpenSearch and we are now starting to have a, you know, technology ready for production in OpenSearch. So you can use the technology now, is test and retest it, so it should be good to go now. It's safe to use, let's say. There are really cool features that we can mention from this tandem, which is the alerted system, which is something that people always wanted to have in Grimoire Lab, specifically some way of being sure that if something happened in my community, in my ecosystem, my project, then I get alerted in somehow. So I may receive an email or some similar stuff. SQL query, if you know about OpenSearch, this is JSON based query format, which is a bit tricky sometimes. So more people are used to deal with SQL, so then you can query with it. So this is coming to the technology as well. And the other one is anomaly detection, which is, again, thanks to the OpenSearch people that are bringing, you know, this is mostly for tracking logs and so on, but because we are talking about activity and so on, if we think about the engineering processes, then perhaps we have certain predictability on how we are producing software, right, in the software production chain. So having certain pointers to certain anomalies in that process, that's really interesting because basically from an engineering perspective, we are able to go to those pointers, look for the bottlenecks, look for issues, and try to solve them. And again, this is already in production, so that's good. Now that I see Ildic around, this is the Open Infra Foundation, this is one of the very first having this, so, yep. More things. So most of the updates we've been having lately on Grimoire Lab are on Shorting Hat. So Shorting Hat is the centralized piece of software that you can use to track all of your affiliations and identity information. And this is GDPR, ready? And over, basically, this has, this is producing more value to you the more time you use it because basically what it's happening and it's part of conversation you had before is you need to keep updating affiliations, you need to keep updating identities, people move from company to other company, there are new pieces of infrastructure that you are using, right? So then all of this complexity is managed by Shorting Hat. And then Shorting Hat specifically is now supporting different backends, specifically GDM or Open Infra ID, but there is now support to produce more backends. So if you are using your own technology to track all of this information, then basically you can produce a piece of software that is integrating that with Shorting Hat and then with the rest of the technology basically Grimoire Lab. Shorting Hat hierarchies. This is basically when used internally in large corporations. So you belong to a company and then you department and then a sub department but then perhaps you have certain skills as Python developer and certain things. So all of this can be tracked. So basically you can check activity by certain departments or so. If we move to the open source world, that means that you can track well different companies, perhaps hierarchies at a different project level. So it's about dealing with hierarchies, whatever that is, right? And then multi-tenancy, so basically it's about having everything in one place which is cheaper and then serving to different customers. So very last updates, you have the URL here for the last release, 0.9, in case you are interested. What you see in the image is basically the architecture of everything. So as Son mentioned before, there are several data sources supported. So 30 plus in this case that are ingested by Percival. So then this is stored in elastic search, open search database. And then it's later enriched with certain pieces of information as affiliation or identities or so on so forth. And then there are many ways to consume the information. You can go for Jupyter notebooks. You can go for out-of-the-box task boards existing in the platform, et cetera, et cetera. So it's basically about data consumption, right? It happens that with Grimoire Lab, you are closer to the business layer of software development analytics, right? So which is community, activity, people, performance, and all of these layers. So a list of supporting data sources, nothing new, look in Google for Grimoire Lab, and then you will find all of these. Yep, more things. In case you are interested in referencing, we came as well from academia. We started all of this like back in 2012. We keep, of course, producing academic papers. So this is something that you can use for reference and have a look at Grimoire Lab in a very detailed way. So with this, and given our background, well, yes, we can say that the, or our goal is to produce high quality, created data sets, all of these affiliations, discussion, consistent reporting, and supporting all of these, so yes, for reference. Okay, some new things that we are working on right now. It's about this discussion of metrics in action. Might be part of the discussion for metrics models in reality. So we are trying to formalize the discussion of, okay, can we have certain thoughts on ecosystem risk analysis? So what does it mean? We've been discussing about ecosystems, right? During this afternoon, basically. I'm using this Georg's comment that we had. It's now in a piece of paper, right? I think it's really good. So basically, if you think about the software production chain, if you try to fix a back in production, that's really, really, really expensive, right? The earlier you're able to detect a problem, the better. But what happens if we are able to predict certain issues even before those happen, basically? I mean, if we are able to predict vulnerabilities using social analytics, which is what we have now in mind. So there's specific academic research on this. They were comparing, this is not done by us, but they were comparing that what if we use, this is Microsoft research by the way, what if we use specific community related metrics to compare to the usual code as males that you have for static analysis and so on. So it happens that the result of this is things as number of engineers working in a certain piece of code, the more there are, the more buggy that might be. Senior developers live in the community, areas of the code that are not modified for a certain period of time. So all of these together so that they were, they had a better prediction for further vulnerabilities at some point. So what if we go up to that point? And I think that in chaos we can play this. We can try at least test the waters and see, is this real? Can we do this? So part of the ecosystem risk analysis is this discussion, right? So can we bring more trust to open source projects to be part of all of this? And perhaps some of the other questions we can have is if we can have a full overview of my whole open source ecosystem risk in a really quick glimpse. So moving forward, basically, this is of course based on the risk working group. This is work on, I mean work on the risk working group, specific a blog post done by Geo here and Luis from Viteria, and the thing is if we can use this to move forward. So there is this URL that you can use risk-analysis.viteria.net, this is fake data, not the very beginning, the first panels, but basically you can go there. Ideally, what we have, and let me go there so I can show you this, it's here, okay. So what you have is our different metrics, right? You have like a factor that you can normalize information against other communities, other ecosystems, other projects. So in this case, we analyze group model up community. So it has a risk factor of 6.9 out of 10. And then there are different metrics that you can have in mind, right? So for instance, the elephant factor is, okay, if you remember the definition of this is the distribution of work in the project across organizations. The more percentage of work done by one company might be more risky, right, from the sustainability perspective. So then you can have different metrics around this, active organizations, active contributors, pony factor, new contributors, which are all related to these social analyses that you can do to predict vulnerabilities at some point, right? And then ideally, then the next step is, or the next question on the table is, okay, we have the project, but what's next? What about the dependencies, right? So then that would be the next step. Again, this is now, we are making up data here. So this is like a mock up and so on. But we would like to know about your thoughts here. So we have project, but then the project has dependencies, so okay, what is the risk of those dependencies? Similar analysis, same metrics. And then at the very end, what you have is basically your whole open source ecosystem, whatever that means for you, because it's not the same an ecosystem for an open source foundation, an ecosystem for a company, an ecosystem for Grimoire Lab, for instance, right? Or for chaos. So those are different definitions of ecosystem. So what if we are able to measure and have a quick view of what this is? Again, this is fake data, so forget about the names on the projects. But if we are able to have somehow a quadrant of all of this information all together, playing with two, three variables, then suddenly you have in a quick view what's going on from a risk perspective, right? So what we are trying to produce here is, we are playing with two main metrics, the risk as core, which is what you saw before, the 6.9, then here is at the X axis, the percentage of your dependencies at risk. And then basically the rest of it is about putting the different projects in the quadrant. So then we can split this into four main areas. Then the bigger the dot, the more dependencies you may have. And it's about, okay, what are my really high-risk projects or communities that are part of my ecosystem? So in this case, you can go for this red one, right? So this would be my projects that are at risk, plus with a high percentage of their dependencies that are at risk. Then we have the opposite, which is this one, right? The green one would be, okay, low risk, low risk at my project, no percentage of dependencies at certain risk. And then the rest of the other two are about playing with those. So then the question here is, what does it mean that these two projects here are at risk for my specific ecosystem? So that depends a lot on what you have on production, how you're using that software, et cetera, et cetera. So then you need to balance this with whatever you have internally. So it's not the same that you are a bank and you are using a project at risk in production, providing services to your customers, that if this is a local internal tool that you can use at some point. So the risk is way different, right? So it's about balancing this somehow. Yeah, and going back to the slides again, just a second. So we can have this discussion now after this. So this is the discussion. The point here is that we have projects, right? And then I enter into the discussion of the ecosystem. But me, if I were a company, if I were a bank, if I were an insurance company, if I were whoever, basically I'm perhaps mostly interested at the ecosystem level, right? Because ecosystem is, okay, what is what matters for me in terms of critical software that I'm using coming from the open source. You as a corporation, as an enterprise, you have certain procurement process to onboard your own vendors, right? That means analyze economic situation, analyze even the background of the employees and time. So you're asking as large corporations many things to all of your vendors. But when we go to the discussion with open source, it happens that some companies are just taking the technology, are just consuming the technology. But that company is not doing any kind of risk analysis on those open source projects. So there is a gap between how consistent you are with your vendors and how this company is consistently not being consistent with the open source projects. So then what if we have a certain way to analyze that risk for those projects that we are directly consuming? So it's part of this discussion here, right? Because all of you with your vendors, you want them to be healthy, right? To grow with you, you want to grow together with them. So what happens with the open source projects? So it's about having this conversation with those projects because if we see that there are a couple of them, or maybe 200 that are at certain risk, probably the next step is, okay, what do I do here? I probably need to talk to them and say, what do you need? Because we had this discussion before like, is this a matter of money? Do we need to put money on the table here to save them? Do we need to, right? So this is part of the discussion to have later at the end of today. But at least by having pointers, because we are talking about at the level of thousands of dependencies, it's really hard to have this. So we need to have a data-driven approach to go to focus or to try to guess what's going on in my open source ecosystem. And risk is one of those aspects that we should be measuring. So, and then we discuss about the importance of the ecosystem, right? Which is why we are all talking today about the ecosystem. So we need to discuss about what risk means for open source foundations, right? It's different than the way that risk means for an open source company, or it means different for care, right? So from an open source foundation perspective, I might be interested in being sure that my projects, the technology that I'm producing is at certain quality level so then others can consume that in an effective way, right? If we think about a company, then the company would like to avoid at all costs any kind of risk related when things are going to production. So those are different ways of looking at risk, right? Definitions of risk. Of course, it's the important of understanding your ecosystem and its participants, basically who is who. And then going to the last one, what we've seen over the years is that the more interconnected, the different projects that your ecosystem are, the more likely that they will be sustainable. So going to the question at the very beginning of what might be a good metric for this interconnectedness might be one of those that we can think about, right? Which is related what you were discussing before, both of you, about the social networks. So what do we have here, right? Yeah, and this is it for today. So we can keep discussing. Thank you for your time. It's great to see you all again. Thank you. Thank you.


Hello everybody and welcome to our journey on the land of microservices. I will have an opinionated talk about different ways of communication between services these days. I'll give an introduction to protocol buffers and GIPC by covering their main concepts. As I mentioned, I will generally talk about things needed for the communication process between microservices. That will include the message sterilization and deserialization of the message, their transport over the wire, of course, the wide diversity of your services in terms of technological stack they're running on from the variety of languages to the variety of platforms that you should support. In a real world use case, you'll have some services that communicate with each other. In this case service A relies separately on BC and D. However, things could look like that. The essential difference is that there are more interdependencies between those services that are not exposed to the user. Denoted by the node A. At the same time, the node A, the user should not even care much about those dependencies. In a nutshell, simplifying the view, there is usually client-server communication. The communication can be done over HTTP and the messages could be serialized to JSON strings. Also, the communication could go over some proprietary protocol and instead of serialized objects in the payload you'll have references to the actual remote objects. We'll come back to that one a bit later. Now considering JSON for object representation, let's take a brief look to its advantages and disadvantages. So first of all, it's human-readable. So it's easy to perceive and debug. It's also schema-less. You have the liberty to form your JSON in any way. There's nothing to enforce you to follow some structure whatsoever. And it's language-agnostic as the serializers and deserializers are available in mainly all the programming languages. Speaking of disadvantages, first of all, it's human-readable and it does for itself. Isn't that a benefit? Well, not really. Human-readable means that it's not too compact. Those it's more consuming in terms of size. Also, it's schema-less. So you ask yourself again, isn't that a benefit as well? Well, actually not, as you always have to map the contents of your JSON to meaningful objects. Not only doing more work, but also introducing lots of repetitive boilerplate code. For instance, when you have multiple clients consuming the same endpoints. In fact, you implement an artificial schema at the application level, whereas it could be done and it should be done on a lower level. Also, there is no type safety whatsoever within the message, which could lead to serious problems when interpreting a value in different ways for different implementations. As an alternative to JSON, we could consider protocol buffers. Protocol buffers are Google language, neutral, platform-neutral, extensible mechanisms for serializing structured data. Thinking somehow, but smaller, faster and simpler. This is the official documentation. I'll add there a small correction. Think JSON, but smaller, faster and simpler. I may refer to protocol buffers later using terms like proto, proto messages or proto buffs. The interface definition language looks like that. The entire content from this slide defines a message. It's called person and it's denoted by the message keyword. It has three fields. The first one is called name and it's the type of string. The second one is an integer. And the third one is a repeated field. A repeated field is essentially a list of items with a denote type. Take a closer look to the numbers on each field. That's the field identifier. It's used for binary encoding and decoding. It is very important to keep in mind that these identifiers should be unique and you should not be reused in case of the deprecation of some fields. To help you with that, to keep track the deprecated fields, there is the reserved keyword. To denote fields that are prohibited to be reused. If by any chance you'll try to reuse one of the reserved fields, the protocy compiler will give you a specific error. In general lines, that's the entire theory behind protocol buffers. Let's see some of their benefits. So first of all, they're binary encoded. So this means that they're very compact and the encoding and decoding process is very fast. Messages can be also serialized to JSON, Thrift or other formats if needed. The schema is enforced from the ideal level. And the messages are strongly typed, which is definitely a benefit over volatile and typed messages. Moreover, having a single way to define messages, you save lots of boilerplate code for serialization and deserialization. It is also language neutral as it has officially support in 10 different languages. And of course, JSON could be even better than that. And it gives us some out-of-the-box backward compatibility features. Avoiding this kind of code. In real world, you'll have various clients and you won't be able to guarantee that all of them are running the freshest app. With protocol buffers, it's easy to add new fields or deprecate some existing fields or even rename some fields. And it's generally faster. From the network perspective, smaller RPCs consume less space and they're transmitted faster. Also, the memory and CPU usage is smaller because less data is read and processed while encoding or decoding a protobuf. Now, this is an ideal message annotation and it's similar to the example that was shown earlier. From this ideal auto-generated code, it's rather simple to create new objects like that. Sorry, this is Java. The generated code provides a view of builder, setters, getters and so on. However, in Python, things look pretty much similar. And for even more elegance, you can use the keyword arguments constructor to construct your objects. Now that you have the rudimentary understanding about the data that's generated and consumed by the services, let's take a brief look to the way these messages are exchanged between the services. In a REST foolish API, usually entities have some distinct URIs. You fire an HTTP request to them, you get some plain text encoded data and you parse it and do whatever is needed. This is how an HTTP 1.1 request looks like.  You'll usually solve that indication with additional headers and perhaps there are some other parameters. The response will start with a bunch of headers again. This is just a small part of them. Surprisingly, sometimes you can receive a bigger amount of headers than the amount of payload itself. This is your actual response payload. With HTTP 2, you could get some performance improvements out of the box. The requests become cheaper as the average request overhead is reduced with multiplexing, header compression and so on. Also, even though HTTP 2 doesn't enforce you to use TLS, it is encouraged to be the only correct way of doing things in HTTP 2. So you'll gain some extra security features. I won't go any further into details as it's not in the scope of this talk. But if you're interested to learn more about HTTP 2 and grasp the entire HTTP 2 evolution, I would definitely recommend watching Annabalica's talk on HTTP history and performance. It is a great talk covering lots of technical aspects. I mentioned earlier the distributed objects. So let's get back to them for a while. In the late 90s and further, the concept of distributed objects became more and more popular. In theory, it looks very nice.  The concept of location transparency implies that the remote objects have the same look and feel as the local ones. From my own perspective, the term should be rather called opaque as your universe awareness is really limited. With this in mind, I'd like to quote Martin Fowler. So the first law of distributed objects is do not distribute their objects. First of all, we should acknowledge the fact that there is a huge difference between calling some procedure locally and going somewhere remotely and doing so. The most obvious difference would be the latency. As a simple local call could take something like a few nanoseconds to produce its output. For a simple network call, you'd expect it to be tremendously slower in orders of tens or even hundreds of milliseconds. Another difference would be the network reliability. A network call may and will fail eventually, whereas a local call will always succeed. So hiding these facts from the user in a transparent object is not the ideal thing that we could do. Also, in the early 90s, a list of fallacies of distributed computing was established by the engineers at Sound Microsystems. And there are the following. The network is reliable, the latency is zero, the bandwidth is infinite, the network is secure, topology doesn't change. There is one administrator, transport cost is zero and the network is homogeneous. Even though the network gets faster, the bandwidth wider and so on, it looks like the entire list is still accurate and still actual. And this is not going to change in the near future. So let's keep in mind Marfa's law, which says that if something could go wrong, it will go wrong eventually. So do not ignore any of the possibilities and be always prepared to handle them. Now JRPC is an open source remote procedure call framework that can run anywhere. It enables the client and the server applications to communicate transparently and makes it easier to build connected systems. JRPC promises us to solve the issues that I mentioned before. JRPC is a recursive acronym. It stands for JRPC Remote Procedure Call. It is mainly developed by Google as a rework of the internal framework called STABE. The first principle of JRPC is to have services and messages instead of references to the remote distributed objects. The message is a static container with type data that respects its schema and it's pretty much all of it. The messages don't have any behavior whatsoever. The service itself has all of its business logic inside so you give it an input and expect a static output from it. In this sense it's pretty similar with the below the restful services with some extra features like streaming. But let's keep it for now. Another important principle is that the stack should be available on every popular development platform. And it should be easy for someone to build on their platform of choice. It should be viable as well on the devices with limited CPU and memory. And for the full list of the JRPC principles you can follow the linked article. A service in JRPC looks pretty much similar to restful service. It has some endpoints and you can pass messages over them. The only difference is that the entity identifier is not a part of the endpoint. As it's usually in other approaches like rest. In the diagram the service is implemented in C++, the clients in Ruby and Java. And that's obviously just an example as any part can be implemented in any of the supported languages. Now let's design a service that will provide routes between two specified points. First of all we need a service. Our service is called route planner. A service can have multiple RPCN points and in this case it has just one. It's called get routes. The get routes endpoint takes a get routes request message and it returns a get routes response message. Now this is a proto definition of the service. It should be kept in proto files just like any other protocol buffer messages. The request and the response messages are defined just like any other proto messages and the location and route are some user defined messages. To generate Python code from protocol buffers definition all you need to do is to run the proto C compiler and it can be done through Python as well. We specify the proto path, the output path for the generated messages and the output path for the generated gRPC specific code and finally the path to our proto file. This will result in two files. The first one holds the proto messages specific code and the second one the gRPC specific functionality. As we already have the generated code from the proto's let's dive into implementing the service using Python this time. So this is basically our entire service. This class implements the route planner servicer that was generated by proto C and each method from this class implements a specific RPC endpoint. It gets the request and the context as parameters. It returns the response message. The context holds RPC metadata like deadlines, constellations and so on. I'll get to this one a bit later. To actually make use of our implementation we create a gRPC server entity with a thread pool executor. The actual implementation has to be bound to the server and then we specify the socket for our service and start it. And that's basically it. As we already have the service in place let's try to implement the client in Python this time. To access the service a client must create a channel to the listening socket then create a stub from the generated code and form the request message. As you form any other protocol buffer object from the generated code. You'll get the request from that in a blocking manner. There's also the possibility to make asynchronous calls when calling the service. And it could be done like that and in a synchronous call you'll get some sort of a future monod in form of Python 3 feature from which you could get the result at some callback check if it's done and so on. The features module is back ported to Python 2 as well if for any reason you still have to use Python 2. Also you can play with your service using the gRPC command line tool. To use it you just have to issue the gRPC CLI call to your socket. After that you write the RPC endpoint name and then goes your request proto. This is just a here documentation. You could also store the proto request message in text files and provide those to the CLI tool if needed. As a result from the gRPC CLI call you'll get the text representation of your response. In this case is a repeated field called routes with the corresponding data. Let's get back to our route planner service and imagine a specific use case. What if depending on the time and some external factors the service wants to get you rerouted as soon as some newer routes become available. This is possible to be done with streaming. In proto definition you just have to add the streaming keyword before your response message and implement it accordingly. Also let's say that our client is accessing our API from a mobile phone while travelling around the city. And his coordinates constantly change. It would be nice after some threshold to stream to the service your new location so the routes could be recalculated as well. Well this is as well possible to be done with the streaming. Now we have separately the response streaming and the request streaming why not have both. Of course we could have both. We just have to add the stream keyword before both of the request and response and voila you just have it. You have to implement it and unfortunately I won't go into implementation details as it's a bit out of the scope of this talk. But I hope that I managed to give you the feel of those features. Now that we know the basics of RPC definition let's try to go into some more sophisticated features of gRPC. And let's keep in mind that things will go wrong and we should be very well prepared for that. When shooting a request it is not fit wait and definitely for a response. There should be always a timeout set. But how do we determine what's the proper timeout for different calls in a chain. Let's try different approaches. We could put a uniform timeout on all the subsequent calls. Let's see it in action. So we have set this 500 milliseconds timeout on all of the subsequent calls in our chain. And first three calls go pretty well. There is still some time remaining from any of those timeouts. Node B for some reason is quite slow. So by the time it responds the client is at the timeout and fails accordingly. None of the nodes are really aware of that. So they are continuing to do the already useless work until their own timeout gets exceeded. And that's obviously not the best approach. In reality for different services we have different expectations in terms of their response times. That means that we can have custom timeouts just like that. For again for the first three calls everything looks good so far. But when the node B responds it violates the timeout by a very small amount of time. So the corresponding node fails. We could have done a better job as probably the entire chain would have succeeded and would have taken less than those initial 300 milliseconds. Let's try to adapt somehow the timeout. An adaptive timeout would sound like a better option. Adaptive in the sense of cascading the timeout from the first call to all the subsequent ones. So let's try the previous example but in this new way. So the initial timeout would be 200 milliseconds and the first call would take 20 milliseconds. That means that the next timeout would be 180 milliseconds. The next one takes 30 milliseconds so the subsequent call would have a timeout of 150 milliseconds. Now we have all the timeouts set naturally from the initial one. The response wave goes well and the client is happy with its result. This looks like a good approach but it's rather difficult to operate with timeouts. The timeout is a relative value, a delta from a specific point. A deadline would mean an absolute value say a time stamp of milliseconds. GRPC operates with deadlines however they're specified by the user in the form of a timeout and it's computed internally. The deadline is propagated automatically within GRPC to all the subsequent calls. You can access the deadline at any point from the context that I mentioned before. For instance, if you do some heavy lifting before making another RPC call and you want to assure whether the deadline is within some normal threshold, you would make another HTTP call and you'd want to manually propagate the deadline there. It's rather simple as you could simply get it from the context. Let's try an example with deadlines and for simplicity let's use a fictive starting time stamp in milliseconds. A timeout value would be say 200 and the deadline would be the sum of those two. Because the deadline is an absolute value all we need to do is to assure at each step that the current time stamp is smaller than the deadline. So we just go and at any step we just compare the current time stamp and deadline and if the current time stamp is smaller then we just proceed. And the entire request response chain goes well and at the end the last time stamp is still smaller than the deadline. So the client is happy with its result. Now let's see an example when the deadline gets exceeded at some point. We have the exact same setup as in previous example but probably a bit slower network. So by the time the request gets to the node A the deadline gets exceeded. A deadline exceeded exception is propagated back to the client. We failed the entire call at an early point so the node B was never touched. This is obviously a good thing to do. In the same way the deadline exceeded was propagated back to the client. A manual cancellation could be propagated. The cancellation can be initiated by both the client and the server. It immediately terminates the RPC and all the subsequent RPC calls that are pending. And keep in mind that it's not a rollback. So if you need for some reason to, if you did some changes, some changes to the database or to some state you should keep in mind to do the rollback by yourself. And it's automatically cascaded as I mentioned before. When migrating for instance adjacent RESTful API service to GRPC a backward compatibility layer can be sure temporarily with the GRPC gateway. This will translate the GRPC endpoints to a RESTful API. Keep in mind it won't work with streams and other nifty features of GRPC. GRPC has a tremendous language support with C++, Python, Java, Go, Ruby, C-sharp, JS, Android, Java, Objective-C, PHP. And it also supports most of the use platforms like Linux, Mac, Windows, Android, iOS. Speaking of success stories, I'd like to mention Google as it's the original creator of GRPC and GRPC is the evolution of Stubby, the Google internal RPC framework which is widely used there for quite a long time. Also the adoption of GRPC externally is evolving rather fast. Companies like Docker, Square, Netflix, CoreOS, Cisco, Carbon 3D, Juniper Networks and others are using it extensively already. For instance Docker container the implements a GRPC API and their swarm communication between nodes is done on GRPC only. Another interesting example is Juniper Networks. They do mostly software defined networks and they implement the SDN open config on top of GRPC. Now summing up let's outline the benefits of GRPC and protocol buffers. First of all you focus on the design of your API and you establish a strong contract with your clients. And you have the schema defined in one place at a different level than your business logic. Also HTTP2 is awesome and it's supported by GRPC out of the box. You have the bidirectional streaming for free and you have the freedom to pick any suitable language for any specific service and you have the freedom to change your choice on specific service at any point. It is service to service and service to mobile friendly and even more importantly it's production ready. So just give it a try. Thanks for your patience. I believe I won't take any questions at the moment but you can catch me at any point later and I'll be happy to discuss anything with you. And as I believe the lunch is already served. Enjoy.


The Lifetime Achievement Award being presented to me, I feel honored and I feel very humble. You do things in your life that you just do them because you want to do them. You try to be helpful, you try to be caring. Having said that, there are an awful lot of wonderful, wonderful people on the board and in the hospital and the medical staff and the nurses and everybody else it's a very much of an honor to be recognized.  He's someone you meet him the first time, he just has this bare hug of a grip and as you get to know him, you know that he just produces good things and he does it with great heart and compassion. He just is good with people and they trust him and they like him and it's never a job for him. He likes it. He talks a little too much sometimes I think. I was born here in 1942 and the hospital was a bit smaller than it was today but the hospital has grown and the family at the hospital I think has grown and this is what's so important. Dick is part of the class of the 80s I would call it, at Winthrop Hospital and we had five new people that joined the 80s and it was one where Winthrop had just, I guess 10 years before that had become a teaching institution. Dick is always there. He brings a long history of being at Winthrop and a real cheerleader for Winthrop. He's a very steady type guy. Dick is a very enthusiastic guy, very committed to the hospital. He's involved with Fred Hicks and is forming the Winthrop South NASA Health System. The hospital was going through a period of transition so he had quite a task in front of him to get these various parts moving in the right direction and I think he did a very good job at it. I have a strong feeling and love for the hospital. Not just because I was born here but because in 2001 I didn't feel very good. I had come back recently from France and I was fortunate to have the doctors diagnose me. I basically had no fear because I thought I was being treated by my friends and I knew they would take good care of me. During the time he was chair he got to have some first-hand experience and so we said that was above and beyond a call of duty. You didn't have to go into the hospital room just to find out how good our service was. I went to visit him in the hospital and his wife Tracy was there and I was there to see how he was doing. And I said, Pat, you got to fill in. I got this, I got that. You have to pay attention to this and this person is coming to that meeting. Tracy got very upset with him and with me that we had to stop that. They had to relax and not worry about hospital business. I think if there's one thing that Dick always focused on it was how did the decisions of the board, how does the strategy of the board working in concert with the administration impact our patients. I think the one thing that I always remember Dick for is one of the champions for the chaplaincy program. That was an effort that needed a sponsor and Dick was a major, major player in making that happen. I'm very proud of the chapel here. That means a lot to Dick and I. We both have a deep faith. I was involved with the chapel through the chaplaincy program and we gave a room in memory of my mother and I think that holistic approach is that doctors can help you physically and mentally and spiritually if you can get that in as well that really the end result is even better. It's been 13 years since I've had a quadruple bypass and I'm not unrestricted. I can do anything I'd like to do and so somebody did a good job. Dick is one of the most caring people you'll ever meet. He cares about his institution, he cares about his family. The only thing he doesn't care about is the golf score.  I have this vivid memory of Dick Newhouse working through the angling of his handicap. On a more serious note, Dick, thank you for your friendship, what you've done for Winfield Hospital. Congratulations. It's wonderful that he's got this award. He's worked very hard and put in many, many hours and certainly deserves it. He's someone who has distinctively gone at his duties and viewed them not as duties but as a responsibility to his fellow man and he's done it with distinction, he's done it with class and first-rate impact. So I think if there's anyone who deserves a lifetime achievement award, it's Dick Newhouse. I don't think he's the guy who likes the spotlight. I think he likes to be behind the scenes and I think he might be a little embarrassed by all the attention. I definitely think he deserves it. As chairman of the nominating committee, I was pushing aggressively for it. He has a good feeling about him that attracts people and he definitely deserves the lifetime achievement award. Dick, congratulations on receiving Winfield Hospital's lifetime achievement award.  It's an honor to be recognized. Let's put it that way. That's it. I'll be honest with you, I don't quite know why I was picked. If you really want to know, you can edit that out. Very humble. He was very surprised and then honored. It was just being him.


Hi and welcome to the session. Let us discuss the following question. The question says, if circles are drawn taking two sides of a triangle as diameters, proof that the point of intersection of these circles lie on the third side. Let us now make a diagram to understand this question. We have drawn two circles with diameter A, B and A, C which are the sides of triangle A, B, C and these two circles intersect at point D and we have joined A and D. We have to prove that D lies on B, C. Let us first write down the given information. Two circles are drawn with sides A, B and A, C of triangle A, B, C as diameters. Both circles intersect point D. We have to prove that D lies on B, C. We have constructed and which joins A to D. Let us now begin with the proof. A, B is the diameter. Therefore, B is equal to 90 degree. This angle is equal to 90 degree because angle in a semicircle is the right angle. Let us name this equation as equation number one. Now, since A, C is a diameter, therefore angle A, D, C is equal to 90 degree because angle in a semicircle is a right angle. Let us name this equation as equation number two. On adding one and two, we get angle A, D, B plus angle A, D, C is equal to 90 degree plus 90 degree and this is equal to 180 degree. So, as angle A, D, B plus angle A, D, C is equal to 180 degree, therefore, B, D, C is a straight line. We have proved that D lies on B, C. This completes the session. Bye and take care.


Okay, is it on? Okay, welcome to the session on physical attacks and masking, the first part of it, there will be another session after lunch. In this session we have three talks, the first will be given by Toma SP2, if I pronounced it correctly, and he will talk about a simpler mitaka, which is a simple parallelizable, maskable variant of Falcon, and Toma will introduce his co-authors. So yeah, thank you for the introduction. So yeah, this is John's work with Pierre Alain Fouk, François Gérard, Mélissa Rossi, Akira Takahashi, Mehdi Tibouchi, Alexandre Wally, and Yonkyu. So first of all, let me make a brief panorama of where we are in terms of lattices for the NIST competition. Among the finalists, two of them are lattices-based, I mean finalists of Round 3, still waiting for the announcement for Round 4, whatever. On the one hand, we have the Falcon signatures, which is the hash and sign type signature based on the entry lattices. It's very compact and fast. However, by design, the range of admissible parameters set is very small. It's also quite hard to implement correctly, and therefore it's quite difficult to protect it against side channels, at least from a masking point of view. On the other hand, we have the dilithium signatures from the crystal suite, which follow the Fiat-Charmier-Witt-Abort paradigm from Lubashevsky and instantiated over generic modular lattices. So it has a larger bandwidth compared to Falcon, but it admits a wide range of parameters sets. It's easy to implement, and therefore it's easy to protect against section, or at least easier. Today, I'm glad to present to you our signature proposal, Mitaka, where we try to reach best of these both worlds. So we want a signature which is compact and fast, which enjoys this large range of possible instantiation to have a fine-grained security, possible security levels. But we also want it to be easy to implement and protect, so that it can be deployed. And also, we want it to be implementable on things arithmetic for constrained devices. So this signature is based on Falcon, so please allow me to get a bit back in time and present to you quickly the rationale of Falcon. So let's say it's a GPV-type signature, and let's say the motto of the author of Falcon, where to have the most compact signatures they could achieve. And if you want to do that, as it is a hash and size signature, you will have to sample in your base lattice. So they took the best preliminary sample we had, which is a plain sampler, but since they wanted it to be efficient, they implemented it as the so-called fast Fourier organization sampler from Duquesne-Prest, which is a recursive version over some towers of subfields. So I'm speaking of that because this choice of sampler forced them to use a very particular type of rings, which are a ring of integer of power of two cyclotomy rings, and they built that upon entrolaticism. So okay, it's very nice, it's very fast, it's compact, everyone is happy, but since we're using power of two conductors, if you look at what are the possible implementation on, let's say, cryptographically relevant dimension, we will have 512, and the next power of two is 1024, so quite fast. Moreover, this FFO sampler is really nice, and from a mathematical point of very satisfying, but it's quite complicated to implement and is therefore very complicated to mask without training those overheads. So to discuss a bit why we changed and what are the changes we meant to construct Mitaka, let me just introduce a parameter, which will be the quality parameter here designed by, okay, alpha, which is basically encoding the width at which you are allowed to sample using whichever sampler you want. So for the case of Falcons, this quality here will be something around 1.17. And since we're in a hash and send paradigm, the quality at which you can sample drives directly the security against forgery. So for Falcons, you have this 1.17 parameter, which gives you something which is NIST level one compiler compliant like 128 bits of classical security. Okay, so this complexity bottleneck, as I said, was this FFO sampler. So what happened if we replace the FFO sampler by something which is simpler and more efficient? So it sounds like a good idea. But as usually in computer science, like there is no free lunch theory, no free lunch everywhere. So basically, okay, you take a sampler which is simpler, but it's at the cost of having a width at which you get sample, which is larger. So it means that according to these quality versus security curve that your security drops. And if you just replace this nice FFO sampler by the hybrid sampler, and I will explain it a little bit later, you're having a huge drop in security. So basically this parameter alpha was dropped from 1.17 to 3. And now you're below NIST level one. So this is quite unsatisfactory. So we wanted to mitigate that drop. And to do so, we replaced the key gen procedure of Falcon. So we improve the key gen, so we get basis with better quality. And as it is a motto in lattice algorithm, if you want to solve a problem which is hard, if you take a better basis, basis with shortest vector, lowest orthogonality defect, then your algorithm will run better. So in our case, with our improved key gen, we are allowed to use these new keys into the hybrid sampler. And we were able to get quality which was better around two. And so we were able to recover this part of the loss of security. So since we've changed the sampler, we don't have this, we're not forced anymore to use this cyclotomic power of two. And now we can implement the wall signature above a wider class of cyclotomic rings, in particular one with smooth conductor. This is pretty great because now we have a lot of different choices in between 512 and 1024. Here are just the example for three smooth conductor. And so we can range quite nicely in between the two and we can reach all possible security level from NIST 1 to NIST 5. So for the comparison, Falcon were only instantiable on the top part of the curve. So now we have full range of possible choices. So all in all, we get a signature which is simple to implement thanks to this hybrid sampler, which is more efficient than Falcon, which is compact, almost as compact as the original one, versatile in terms of parameters, and which is maskable. And I will come to that at the end of the talk. Moreover, we can actually tweak again this hybrid sampler. And it allows to have an implementation in fixed point arithmetic, which can be interesting for constraint devices. So that was for the whole rationale of the scheme. And for the rest of this talk, I will focus on describing what is this hybrid sampler and how it's important for the security and on what we did for the improved key chain for all the other part I will let you refer to the paper. So to dive a bit into the details of the signatures, let me make a brief recall on how you construct hash insight signatures over lattices. So everything comes back to the GPV framework from again, and to hash message into within this framework, you first hash your message somewhere around the somewhere inside the ambient space of your public lattice. Okay, you have a point M, it leaves somewhere fine. Then what you do is you sample a Gaussian around the around this hash point M. And you want to sample a point which is not too far for reason I will explain. And then your signature will simply be the difference between the freshly sampled point and the hash. Now how to verify. So first of all, of course, since I said you're sampling a short vector, a vector which is close to M, sorry, this signature S must not be too big, it just could not appear. Then you also want, this is like functional verification, that the difference M minus S to belong to lattice because since you are doing Gaussian sampling in a lattice, of course you belong to the lattice. And then if these two conditions are satisfied, that's a valid signature. Okay, so now you can be like, okay, what's the relation with hard problems in over lattices. So if you look at the two conditions for verification, it appears that what you want to do to forge a signature is just to be able to find a close point to M inside the public lattice and close meaning by this S is too big. So what you are actually trying to solve when you are forging is a closest vector problem instance. So you want this close vector problem, approximate CVP to be hard in your lattice, otherwise you could just forge.  So in this, in the, sorry, step two, to be small because if it's super wide, of course, like forging will become easy because your approximate CVP will be like with huge factors. You want to be able to small to sample sharp cushions. And if you remember the lattice algorithm motor, if you want to solve this hardware of sampling sharply in your lattice, you want to have a good basis basis with good qualities or short vectors and or a smaller thing that it affects. So all in all, your secret key will be a base, a good basis of the public lattice and the public key will just be whatever basis. So it should be hard of course to compute this a secret key from just an edge of public key. Of course, otherwise you're allowing to have a key recovery attack. And since you want a practical scheme, you want to, you want your secret, your public key to be easy to generate from the knowledge of secret key. Such a secret key is called a lattice trapdoor and generating trapdoors for sampling has been a very interesting challenge in the lattice committee for like two decades almost. Okay. So that's why this explains why we want to have this good basis, good trapdoors and why we want to sample. So now like how do we sample over a structured lattices? Okay. So for efficient Gaussian samples like polynomial time, the idea is that a lattice Gaussian sampler is a decoding algorithm, CVP solver, on which you add a randomization. So two well-known Gaussian samplers are known, polynomial time Gaussian samplers. One is the famous Babay-Rondoff technique, which is basically the following idea. If I take a point near a lattice and I write its coefficients inside this basis, the coefficients will be real or rational. And the lattice points will have exactly integral point, integral coefficients. So what you just do is take the coefficients, run them, and then you're done. Simplest algorithm you could imagine. Neat algorithm, which also exists, is so-called Babay nearest plane, which is a bit more tricky to implement, which basically take lattice hyperplanes and carefully choose close enough lattice hyperplanes and recurs to approximate your solution. And I say you want randomization on the top of that. So what do you do? For instance, for Gaussian sampler, you randomize this whole integral rounding thing. So if you just do that, you will have some little issues because your distribution will not be zero-knowledge with regards to the basis. But like I could show that if you do this randomization and add a tiny bit of convolution by some carefully chosen normal distribution, you have a perfectly nice zero-knowledge sampler. And if you randomize this Babay nearest plane, so it means that you're randomizing the hyperplane you're choosing, then you will get the Klein sampler, which is the one which is a basis from the Falcon signature. And in between, for structural lattices, we have a lot of space. And for instance, there is the Ducan-Pressed hybrid sampler, which is a trade-off for modules over rings, where this rounding, as I said, on randomization is now not done at the integer level, but it's done at the ring level. So somehow we are doing like block rounding instead of just rounding point-wise. Just to give you a rough idea of how these things compare, so this quality is the alpha I showed you on the graph a bit earlier. So the Pitered sampler randomization of Babay Randolph will have a quality which depends on the largest singular value of your input basis. So the Klein sampler, the randomization of Babay nearest plane, will have a quality which is related to the max norm of the Gram-Schmidt vectors of your basis. And the hybrid sampler, which is somehow a mixture of the two, will have a quality which depends to the largest singular value of some Gram-Schmidt organization at the ring level. So it's pretty current. So the Pitered sampler is very fast and simple to implement, just like how the Babay Randolph is very simple. However, it has the worst quality among the three. So the worst quality means the lowest security. The Klein sampler has the best quality among the three, so the highest security, but it's slower and more involved to implement. And this in-between hybrid sampler is a good trade-off when your ring, sorry, admits a good basis with nice geometrical properties and so on. So to fix a bit some ideas, if you try to, if you take out the ring, the convolutional ring used in N true, so cyclotomic power of two, you can compare more explicitly the quality you can reach. And you see that this Falcon sampler will have a quality which is constant, essentially, whereas the Pitered sampler will have a quality which depends, which grows on the power of one fourth of the dimension. And the hybrid lies actually in-between as expected. So it's pretty, up to that it's pretty nice. So as I said, so since we took a sampler which has a slightly worse quality than the Falcon sampler, we need to add something to be able to recover the security loss. So we call that from the first slide. So if this is like the case of Falcon here, just replacing by the hybrid sampler makes a huge drop in security because your quality also increase. So how do we improve the key gen? Okay. To understand how to improve it, first let me recall like what is the base key gen? So the entral lattice is constructed as follows. So if I take two elements in my ring R, F and G, I construct a public element A which is the quotient G over F mod Q. Okay. Then the entral lattice will be the priority check lattice associated to A, which means I take the orthogonal to the vector A minus one or other way to say it.  So I said that the trapdoor was a short basis with good quality with regard to the sampler process. So, okay. I already know some F and G's which are presumably small and now I want to complete this F and G in some basis of the lattice. So I can do that actually because this lattice, the lattice is fully determined, the entral lattice is fully determined by A or fully determined by F and G. And as such, knowing F and G allowed me to recompute some coefficient I can put here and here to have a basis. Very interestingly, this can be done very efficiently by applying some variant of Euclidean algorithm and using the geometry of the ring to have some efficient process. What should be remarked at this point is that I said that we want a good quality with regard to the sampling process. And the quality as a nice property that it can be computed only using F and G. We don't need to complete the basis to be able to have an idea of the quality.  For instance, for Falcon it would be something like that, for the hybrid sampler it would be something like that. And I will just wait until my good event happens. Oh, suddenly, yay, I have my good basis. So if you write that as an algorithm, absolute code, you will get something like that. You sample F and G gaussians with the norm you want to have and you wait and you do your quality check until you reach a good basis. So for Mitaka quality you can think that, okay, I can do exactly the same. I just replace the quality condition and I will get a nice basis. However, the reject and restart already happens quite often in Falcon and if you want to reach the Mitaka quality, so here, you will need a lot of restart. So this is not really acceptable. Since like having like generating gaussians and gaussians and gaussians all over will be quite expensive, what you would like to have is to reuse the randomness. So basically we can sample a pool of random vectors and then combine them by convolution to generate a larger pool of gaussians and then use the Galois automorphisms of the field because since everything is nice, we're working with our entrelates, we have cyclotomic fields, we have lots of free automorphisms and you will have a free blow-up of the search space. So you have a small pool of randomness, smallish, then you expand it and then you add the Galois automorphisms to expand it again. So you have quite huge search space and then in this space you can find better troubles in quite reasonable. So all in all, I said that Mitaka was actually maskable. So a quick word on that. So usually the standard security model is the standard attacking model is a T probing model in which you basically said that your attacker can probe T values at the runtime. Then the security you want to achieve with regards to this model is a T probing security and that you basically say that if the attacker can take T values, then these T intermediate variables should be independent of the secret. If they're independent of the secret, I can't recover any information on my secret, I'm happy. So to get an implementation of Mitaka, which is T probing, T probe secure, we use arithmetic masking. So the idea is here is inspired by secret sharing. So if I have a value I want to protect, say X, I will sample T plus one values independent, but conditioned by the fact that their sum is equal to X. So that if I take T values, if the attacker can take T values, he will just see random noise somehow. And then actually this arithmetic masking is linear. So every linear operation done in the sin signing parties is nicely compatible, but the multiplication can be slightly tricky. So since it's polynomial multiplication, we work in FFT domains so that we transfer the polynomial multiplication to be a point-wise multiplication. And then we use a standard multiplier. And then the interesting fact is that we can mask all this Gaussian generation process because if we use shares, which are actually Gaussianly distributed, if you sum Gaussian shares with the right parameters, you will get a Gaussian in the output. So basically we can use this nice stability property of Gaussians to have a masked way of masking the Gaussian generation. And to conclude with a bit of implementation results and practical things. So we did some experiments on a non-masked and non-constant time implementation, even though it can be made constant time with standard results in the literature. And it appears that we're using Falcon C as a reference code and also using some part of it, such as the FFT. We have a scheme which is roughly two times faster than Falcon. So it's not really a surprise because if you count the number of multiplication you're making in the wall sin signing algorithm, you have like half multiplication on each other. So to wrap up, and I will finish with that, we presented a variant of Falcon, which uses hybrid sampler and an improved key gen to have nice security properties. It's simple and efficient. It's compact, very versatile, and is maskable. So I thank you for your attention. Any questions? If you don't mind, I have a couple questions. You mentioned it was slightly larger than Falcon. How large are you compared to what Falcon does in terms of signatures? What? So can you repeat the question? Your signature size is much bigger, but not that much. Yes. So for Falcon, let's say Falcon 512, the signature size, if I remember correctly, is 666 bytes. And so if you implement Mitaka on 512, okay, maybe you can see because you're on that. Okay, so for the lowest security parameter, we'll have something which is around 700 bytes.  I don't remember exactly for 1024, but yeah, it's like the, let's say 15% bigger. But actually, so as future work, we know how to reduce the size of the Mitaka signatures to have exactly or even be below the size of Falcon. Thank you. Any other questions online or from Doom? If not, let's thank them again.


Hi everyone, Joe for jaspyscasebrakes.com coming at you with 2020 Top Diamond Icons Baseball One Box Random Hit Number 6 from jaspyscasebrakes.com. Ten hit break, everyone's guaranteed a hit but a random hit. Big thanks to the people who bought spots straight up and congrats to the two people that won spots in that select mini box break. We're going to type in all the hits right here. Once we open up one of these boxes, so I'm going to select a die, we'll go with that one, and we'll go 1, 2, 3, 4, 5, 6. Last night we did box number 4. So 1, 2, 3, 4, 5, 6, so we'll do that one right there, 1, 2, 3, 4, 5, 6. So first box, we'll save these for next time. Alright, now let's see what's inside. Good luck. Put that over right here, over the cards, alright there's everything right there. Next up we're going to lead off with Nolan Ryan, 14 out of 25, and we'll type in the hits, once I show all of you, we'll type in the hits in the order that they were pulled. I think all the cards are facing that way, alright. Next up is a nice patch auto, David Ortiz, 4 out of 25 with the MLB hologram sticker there. If you go to mlb.com, slash authentication, you'll be able to check out what date that jersey came from, maybe you can see if Big Poppy made a start that day, then look up his box score, his game log, and see what he did that day. Very nice hit. Next up is Mark McGuire, Big Mac, 3 out of 25. When's that Mark McGuire, Sammy Sosa, 30 for 30, coming out? Nice Juan Soto, Silver Inc. autograph, 18 out of 25, he's got a good looking auto. Next up is Whit Merrifield, 12 out of 25, nice patch, nice autograph. Next up is Jeff Bagwell, 16 out of 25, part of the killer bees, Bagwell, Vigio, I forget the other, there's a couple other bees. Rod Carew, Red Inc. autograph, 17 out of 25, Berkman, yeah Berkman, Daren and Riffer, I feel like there was another bee. 20 out of 25, Jesus Lazardo, Red Inc. autograph, Eloy Jimenez, nice, 15 out of 25, you got Juan Marichal, 20 out of 25, Red Inc. autograph, old school giant, good looking stuff, and the last one is, should be the relic, yeah, Pedro Martinez, 9 out of 10, Jersey, nice, so there you go, we got 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 and 11, maybe we'll combo up, leave these guys alone, leave these guys alone, that has a relic in it, that's a rookie, that's Eloy Jimenez, we're going to put Juan Marichal and Pedro Martinez together right here, alright I'm going to pause the video, we're going to type in the hits, when we come back, we're going to see who gets what, be right back, alright welcome back folks, so I got the hits all typed in here, there's 1, 2, 3, 4, 5, 6, 7, 8, 9 and 10, should have 10 names here I hope, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, perfect, alright let's roll it, let's randomize it, 2 out of 6, 8 times for each list, your names first, 1, 2, 3, 4, 5, 6, 7, and 8th and final time, after 8 we got Jimmy Brent, down to Jimmy Brent, 8 times for the hits, 1, 2, 3, 4, 5, 6, 7, and 8th and final time, after 8 times we got Eloy Jimenez, down to Rod Carew, hall of fame Rod Carew, alright so here we go boys and girls, Jimmy you got the Eloy Jimenez red ink to 25, John Salone with the Whitmaryfield patch auto 12 out of 25, Steve you got the Juan Soto, nice silver ink autograph to 25, Brandon with the Nolan Ryan and the Mark McGuire, Jimmy with the Jesus Lizardo, Kevin with the Juan Mirachal red ink to 25 plus the Pedro Martinez relic 9 out of 10, Keith with the David Ortiz patch auto 25, John with the Jeff Bagwell to 25, and Jimmy Brent with the Rod Carew red ink autograph 17 out of 25, there you go ladies and gentlemen thanks for getting in, got a couple more boxes from this case that I'm sure we'll be posting at some point tonight, so keep an eye out on jazzy'scasebreaks.com and I will see you next time, bye bye.


International Airport, outdoor sculpture garden, and I am on my way to Beirut, Lebanon. I'm traveling during COVID-19, but then when I land, I do have to quarantine for 48 hours in a hotel. So it's a lot. It's different to travel during this time period, during this time of the coronavirus internationally. It's not like just hopping on a plane and flying off to another country. There's a lot of hoops, a lot of paperwork. It's nothing compared to what the people of Lebanon, people of Beirut are going through right now. They are going through multi-layers of Christ's disease right now, and I can't wait to get there and connect with the people of Lebanon and see how I can be of any humanitarian support. Me going there is an initiation by Code Pink. We hope to let our friends in Lebanon know that they are not forgotten and we want to hear their stories. We also want to provide some humanitarian funding to support the folks there. But anyway, I'll report back later and crossing fingers this travel goes through without a hitch. Thanks.


this is how to get radial access. We first give some Laticane. We then palpate the pulse and use a 21 gauge needle to get arterial access. We then insert a small micro wire through the needle, remove the needle, load a sheet onto the micro wire, push it through the skin and into the artery and remove the dilator.


One hallmark of a four is being attuned to the feelings and emotions of others. I feel deeply not only for myself but for other people and I'm especially in tune with pain and suffering. When I'm healthier in a good place I'm able to focus and hone in on the principles and objective morals of my integrated one. This combination gives me a unique perspective on issues of justice and restoration, both the intense emotional component that allows me to relate and the drive and motivation to take action.