I could project, but why? So just to kick off with a little bit of a story, I live in the Northeast and lost power in a really bad northeaster one time.  But so I was in a pretty big home automation phase without the time. And I had installed the hub, the light bulbs, everything else. And they all follow a pretty common pattern. They connect up to some REST API in AWS, bad news if US East one goes down, or Cloudflare as it was last night goes down. The mobile app calls some endpoint and message comes down from that service down to the light bulbs or anything else and turns them on and off. I mean, I'm sure everyone here sees the problem in all of that. So northeaster comes through, nails is pretty bad, and our power came back within a day or two. But internet and cell tower was out for three days. And so being stuck in the dark for three days gets a little old after about 48 hours in when you can't turn those on. So think about these problems a lot. Think about a lot of local edge embedded software and how to fix some of the problems that we're in. So I'm Jared Dillon. I'm the CTO at a company called Mycelial. We are building out state edge networks and doing that with WebAssembly and building out development kits and clients. So you'll probably hear a lot about server side WebAssembly throughout this entire conference. We look more at the clients. We look more at the edge. And we just raised $3.8 million through Crane, who is also believing in that vision of better connected clients. And if anyone's interested in those problems instead of the server side, we're looking for people. So yeah. So I'm going to talk about a mixture of things in this talk. And half of that will be a little bit of the embedded systems imply a lot of clients and at the edge. And so you end up with a lot of different problems that are unique to these devices out in the field, not just in the fact that some of them may be running real time operating systems, but also in their modes of operation. So if we're looking at today's orientation towards a client's server dimension of the gravity of your services and the scaling of your services with very thin clients, this doesn't work very well in an offline or peer to peer or a local first environment for a lot of reasons.  You're relying on data centers far away to do that. And we have more compute out there than ever before, closer to us than ever before. If you think about what's in your pocket or just what's in this building, there's massive amounts of compute all around us. So today we're going to do a quick survey of the embedded edge. We're going to look at WebAssembly at the edge. We're looking at WebAssembly and embedded in real time in OS environments a little bit and embeddable clients. And then kind of take a look at an embeddable WebAssembly runtime we're working on open sourcing and upstreaming. And then I do have a demo. I have a video of it. At the moment I managed to fry the demo device. I have a backup. So if anyone's interested in this, there's contact information at the end. I'll be able to show it once I reflash it tonight. As I was preparing for this today, I found out that I had bricked it. So all right, what is my cloud made up? Well, right now if you look at the environment where we have that large cloud, little edge universe, we have these virtual machines ultimately connected with RAFT, especially if you're using something like Kubernetes or Mezos, serving millions of these clients, these IoT clients, these embedded clients, these edge clients. And we're taking all that data and we're putting it into these massive data lakes and proceeding to do data on it. Now there's been advancements here where we're not running these giant Hadoop jobs anymore. Some people are, but we do have things like us, now are doing like SIMD, JSON, and we're able to at least query and get an understanding of this data. But we're trying to make decisions about that data. And we're trying to scale this out by adding more availability zones and regions of which these large clouds only have so many. And it's the making decisions about the data that I really want to talk about because these edge embedded devices are really all about making decisions out in the real world. Now if you're building out a driverless car, making a decision up in AWS is probably not what you really are intending to do. So as I said, the availability of compute is massively growing out in the real world and quickly outstripping non-IoT devices. ARM is everywhere, RISC-5 is everywhere. It's going to continue being everywhere. And we're even seeing ARM in the cloud, but low power available, ubiquitous compute everywhere that in a lot of ways right now is probably underutilized if it's just collecting and pushing sensor data up to cloud services. So as the movie might say, what do planes, trains, and automobiles all have in common? Well, if we look at a plane, it's sipping power. It's using as little power as possible to put all of that engine thrust and be as efficient as it can be. But it has many sensors all operating at low power. It's generating off all of those sensors a massive amount of even redundant data. You have angle of attack sensors, you have avionics data, you have fly-by-wire. These are all very complicated real-time OS systems. And that's before you can consider anything in the cabin. That's just what you interface with on that plane. And this is a real-time system. And I will take it aside and talk about real-time systems because I think in a lot of embedded real-time becomes a very important concept. And the difference between hard real-time and soft real-time. Before I go into that, many people have a strong familiarity with hard and soft real-time. OK, couple. So we'll dive into that a little bit. And in a plane, you have, at best, satellite networks. There's radio, there's other forms of communication. But you're not pushing avionics data all the way up beyond the resolution of what flight radar is getting. Now, you look at a train. And a train is basically a massive power plant on wheels. And we talk to and we work with some people in this arena that effectively, they tell us that they can run an entire data center on that engine, and their next generation engines, because it's just a power plant on wheels if it can survive that 150 to 160 degree environment. Also, many sensors, a lot of these are trying to do predictive maintenance. We're looking at freight engines now that have 30,000 sensors on them to try to make decisions out in the middle of nowhere. Again, massive amounts of data. You're collecting data about the track. You're collecting data about the environment, about the locomotive itself. Trying to identify, next time that comes into the yard, does it need to be pulled? And again, this is making hard real-time decisions. If you miss a signaling decision, you're creating a catastrophic error. And a lot of these environments, you're looking into the middle of Nebraska. You're looking at the middle of your places with no power, no network going out to where you just have to make local decisions and how do I, as a developer, create software that can interact without that network and make decisions locally, but also get that information back. And we'll talk a little bit about that shortly. And then we look at cars, right, especially self-driving. In reality, we're talking about a limited power environment. I mean, my alternator can probably charge this laptop. I mean, you start to get too many devices and you start to notice a big draw there, but you look at modern cars, again, many sensors, lots of real-time data, especially lane assist, especially those sorts of technologies, real-time, and you may or may not have network, right? So you have to be able to operate an environment where you don't know if you're gonna have network or not. And what does that mean for the development environment around you and how do I robustly develop software where I don't know if I'm gonna have a network at a given moment, right? So what do they have in common? Well, they really have all of their constraints in common, right? Despite some diversity in their power and sensor needs, the big thing in common is that these are embedded devices that are basically spitting out massive feeds of data at all times, and they need to make decisions about it in real-time no matter what that network availability is. So this gets us into those real-time systems that effectively have unlimited compute relative to the device. You throw a couple of, I mean, even modern Raspberry Pi 4s in a car, and that's a lot of compute power there available to those systems. You throw FPGAs with RTOS in there and it's even better. You have dodgy networks, right? And you can't shove all this data into the data lake. It would be impossible the amount of data that this throws off. And so we usually start to do things like summarize that data, right? We start to take Windows and time spans and drop data. And we're talking about these systems being networks of their own, of interconnected devices local to that environment, right? That all have to go coordinate much like you would in any other data center except it's embedded devices and you don't have any elasticity to it. So I just wanna talk a little bit just so everyone's on the same page about what real-time is that that term gets thrown around a lot. And I think it has a different connotation when we're talking about these sort of environments, these sort of devices. And so we have hard real-time and soft real-time and we're really talking about degrees of latency and tolerance here. Or system degradation in the event of any sort of this intolerance and so quality service failures can have varying levels of catastrophe. So hard real-time systems, we consider that a total system failure if QoS guarantees are not met. And we consider soft real-times degraded. So these systems at the edge are a mix of hard and soft real-time systems and how they interact with the real world, right? A hard real-time failure is very catastrophic for a plane if avionics fail. But if there's issues with your streaming in-flight video, your experience is degraded but you just might have to talk to someone next to you or pull out your Nintendo Switch instead, right? You're fine by comparison. And so that's the difference we sort of look like, look to in these systems and how we think about decision-making in these systems and the data we're generating out of these systems. So, well, why does this matter? If you, and this is kind of a weird slide to throw up here with a bunch of streaming network services that are coming from the cloud, and you have Mighty up here, I don't know if anyone's seen that, but it's streaming Chrome right to your, right to your thin client on your computer. You have streaming gaming, you have streaming for code with Gitpod and VS code remote plugins, right? Or code spaces, that's what it is. So, we're talking already about like very, like more and more and more of a world becoming very latency sensitive, right? If we have dead environments being streamed, then you expect when you type a character it's gonna respond. If I am playing a game, again, latency sensitive, I'm gonna move my mouse, I'd expect the mouse in game to move, right? And so we're seeing this cataclysmic shift from to using this massive amount of computing power we have in the cloud and not using any of the computing power we have out in the edge. And if you look at it, like there's many definitions of edge, some people would consider the, you know, your last point of presence for CDN and Edge. And sure that's technically true, but for the purposes of this talk we're talking about those far out and client embedded edge devices. But the assumption remains the same, right? The network was always gonna be good. Everyone's gonna have a great time, you know, fibers everywhere. And the consequences of network outages is just some lost productivity, right? Or you're kicked out of a game.  So what does this matter? And this is gonna start leading us into a bit of the web assembly part of this talk, but there was a very interesting talk from Peter Levine, or I guess Talk and Blog Post. The end of cloud computing, and I encourage everyone to go read it because it very much impacts these sorts of devices that we're talking about. And it's called, yeah, the end of cloud computing. And so I'm gonna read just two excerpts out of that, and we'll talk about the excerpts as we go.  Sensors will produce massive amounts of data. And this was written, I think in 2018, we're four years removed from that post. I think we're seeing it more than ever. But existing infrastructure will not be able to handle the volumes or the rates. Data will be stuck at the edge, right? That's a very important thing. Too much data at the edge, too much data coming off these embedded devices to get it back. And computing is gonna move along with that data to the edge. And I think we've seen a little bit of that with move compute to your data instead of data to your compute, right? We haven't quite seen it like this at the edge, but we're going to and we are. And this is, you know, that's what we're working on. So we're absolutely gonna return to a peer-to-peer computing model where the edge devices connect together, creating a network of endpoint devices, not unlike the distributed computing model. It goes on further to say, real-time processes will need to occur at the edge where real-world information is being collected. So again, we have these massive data streams we're wanting to make decisions. We have to do the compute there. The notion of real-time becomes a very important ingredient given the massive amounts of real-world information. And we're not just talking about text information, right? We're talking about collecting video and streams of information. Both these things need to work together and data will absolutely drive this change, right? We're not just talking about just values. We're talking about structured data. We're talking about audio. We're talking about text. We're talking about all sorts of rich formats optimized towards their environments. And some of those, especially in, we're talking about CRDTs or collaborative models, are partial information updates, right? For what you need to make a whole. So why does this all matter? Well, at the edge, we really want to do some sense and fur and we want to take an action. And he refers to this cycle. And this is really the core function of a lot of these edge and embedded devices, sensors, and things that act upon them. We want to gather some information. We want to make an inference on it and we want to make a decision and do something, right? But we want to get that data back. And he stops with this idea of learning. So we want to then take some of that information and say improve our models. We want to make a better decision next time or make a better decision for other clients in light of new information. We then want to process analyze. We want to actually go and update those back out, right? It's one thing to go learn from it. And I think this is where we see a lot of current efforts, the improvement and where web someone can really help. And like I said, we'll talk about that in a minute, but actually going and updating these devices to go a match in a lightweight way that takes into account everything we just learned from those decisions, right? Make the whole of these fleets better. So we're all used to, I think, a lot of cloud data was used to dev and packaging. You have containers, you have Kubernetes. You're acting with processes. You have some sort of observability model and you have plenty of ways of doing data in comms and between streaming systems and long-term data storage solutions. So we need some new building blocks, right? And one of those building blocks that I look at a lot or relook a lot is using WebAssembly out in the edge and out at and embedded. How familiar is this room with WebAssembly just before I give a primer? Okay, lightly, so great. So let's just talk about what WebAssembly is. There's a lot of blog posts. There's a lot of like, I wouldn't say it's fud, but everyone gets very hyped up when they start talking about it, but it's really all it is, is a binary instruction format for a stack-based virtual machine, right? It's a specification and it's a compilation target. So what's interesting about this is we both have a specification for a virtual machine and it's designed in a way that anything can go or as many things can go compile to it as possible. So you have this interesting fixed point between the things that run WebAssembly and the things that can compile to WebAssembly. And then for those who are still interested after hearing that, well, you get a lot out of running WebAssembly. Now there's some restrictions and I'm sure you'll hear about a lot of those throughout this conference if you're going to other WebAssembly talks, but you get a lot of benefits out of that too, right? It's very size and low time efficient. The binary format is very compact. The text format looks like a Lisp and it's structured like a Lisp. You can get this executing at native or near native speed. Not every runtime will do this, not every language will compile. You're still going to pay the cost of your language, right?  But if you're running C, you can get about 94, 95% the speed of C right there and you can do that very efficiently. And one big thing about WebAssembly is and if you've heard of WASI, WebAssembly System Interface or Web Components, we'll talk about that a little, but it enables an abstraction for a lot of common hardware capabilities. Now we're, and this one deserves a star by it. It's memory safe and is in a sandbox execution environment. Now, Spectre does exist. Attacks do exist, right? There are side channel attacks, but it's about a sandbox as you can possibly get and that's going to be very runtime dependent. There are ways around that. A bit beyond the scope of this talk, but I'm happy to chat about that. And I think one of the most critical things about WebAssembly that gets is what people are super excited about it is it is very embeddable that you can do today. And so we wanna be able to perform like a really fast reliable prediction every time a state change happens, right? Okay, well, this drone has new information, let's go detect if we're about to hit the ground, right? Or we're falling or whatever. And then we go update the state of the drone with the decision made. And because we're using WebAssembly and this is running on the same hardware, the same physical device, we're not, this team is potentially not an expert over in WebAssembly or sorry, in TensorFlow models, right? But this team is. So they wrote that as a TensorFlow model, compiled it down to TensorFlow Lite, deployed it out, now it's running. Now there's something interesting there, right? We've now sort of made this team fungible instead of having an entirely just embedded team running and building and trying to maintain this device. And it looks a little bit more like the infrastructure that you might see in say, containerized cloud-native environment. And now we perform an action, right? We send a signal to physical systems, we're gonna run a bundle for that instruction, maybe we've written to that in Rust or maybe we've written in C or AssemblyScript or something else. But the team that's the expert with that, that particular actuator can now sort of go and own that part of the system. Now we wanna go learn for that, right? Like, we wanna go even further because now we've composed our system out of these reusable building blocks that can run at the edge, we have hardware abstractions, and there's no reason, and I'll show a little example of this too. Whoops, hang on, I realized my notes are, there we go, there's my learn one. So we wanna then go synchronize the minimal amount we need back to the cloud in order to do a partial training update, right? And so now we've gone, we've gone and updated the model, we can go push that back out to all these drones, and we've actually improved the totality of the system by sending the minimal back instead of trying to send out this massive feed of data. And there's no actual reason before I go further, I think I have another slide on this, but there's no reason because of these abstractions, we can't actually go simulate this in the browser. One thing that I think is very compelling for WebAssembly outside the browser is that you can put it back in the browser. And so instead of having these device labs, you have a high fidelity, we have these high fidelity environment that basically mirrors out the state of a real world device. You clone that with its real data, you can go see how it acts, you have everything you need in order to go make a high confidence decision when you go to update with one of these. So just a quick survey of various WASM run times for embedded, for the worth going and taking a look at. And we'll talk a little bit about compilation style here as well. So WASM time is sort of the canonical byte code alliance runtime. It is a full, just in time compiled VM for a runtime for WebAssembly. And it is, I think probably the most used if you look at a lot of the users and out there, runtime out there. But one thing about these run times is they're intended to be portable, they're intended to be bindable, right? You can actually sort of swap these out depending on what you need. The, and this is for the demo. Once I get this back up and running and the video is actually using the WebAssembly micro runtime. And I started that because it's a little bit different. It's actually using a different page size. But the idea is, is you have a runtime that can go fit on the tiniest of possible devices down to little originals, down to these sensors. And that's the case for WASM3 as well, which is an incredibly fast interpreter. You have WASERO, which is by Tetrate Labs. It's entirely in go. And intended to be compiled with tiny go as well. So you could actually go and compile this in theory to WebAssembly or down to an Arduino device and have it a jitting or interpreted runtime there. And you have, and there's plenty of others. In fact, I think Michael from WASM Edge is in the back there. He'll be talking about WASM Edge later, which is another great runtime, especially for machine learning. So, a quick note on compilation style. This is how it really is matters for these embedded environments. You're often flashing a ROM, right? And so being able to come in and jump instructions, being able to do a full jitting compiler can be really difficult in these environments. And not only do you have to rely on generating, or jumping to native instructions in the case of a JIT, but you also have to build out for each platform. So interpreters can actually be very useful here, even though there's technically the slowest mode of execution, but you just need to get that interpreter pointed or ported to every single environment that you could possibly run on. So, there's pros and cons, but the biggest thing is here really, there's a lot of WASM runtimes out there, but there's not really one for every single job, right? So it's worth taking a server. It's worth evaluating the runtimes out there depending on what you're doing. So what we think about more is with what we're doing, we're not really thinking too hard about the runtime itself. We try to be very runtime portable. We're really thinking about what's that abstraction look like? What's that look like over hardware and over sensors and over these clients? So there's gonna be some talks on these, I believe, but we're looking at things like the WebAssembly interface types and component model. The entire idea here is about shipping out WebAssembly components that can co-interact with each other natively. So you have a Python module interacting with a Rust module and being able to publish that out, right? Or being able to publish interface types for a temperature sensor that's also running and being able to do that portably across languages. And so you have the WebAssembly system interface that looks to port SysCalls. Now, a lot of embedded, you don't have SysCalls. So we're really looking at the WebAssembly device interface, which we're looking at for contributors for that's looking at, how does this look with I squared C? How does this look like with GPIO? How does this look like with more physical IO devices? And so getting into that runtime, we're really looking at having sort of an environment for applications to run in that takes the underlying system hardware, ports it up, has the WebAssembly, has everything needed to go push updates, to go get data back, and the user does not need to think about these low level details in order to run their application. And that application is very portable, right? So you have one that's optimized out for a Raspberry Pi, you have one that's optimized out for even an Arduino, and then you have one that just runs natively and seamlessly in the browser. So the important thing here is that, I'm trying to be mindful of time, that we're really looking at the user focusing on their application, right? What am I actually building? And thinking about synchronizing the state and not worrying about these big event systems, right? You have MQTT, you have a lot of ways to get events back and forth, but if you're in bandwidth constrained environments, trying to send every single event becomes incredibly expensive if you can do it all. We're back to facing that data streaming problem, right? And it doesn't help that a lot of these messaging systems are not designed to run as a distributed database, right? If you lose quorum on your Kafka cluster, you're down. And this is not the case with these devices that have this intermixed, intermingled, and spotting connectivity. And then just eliminate all the user-level code for working with low-level networking, storage, display, IO, all the device details needed for these clients. The other important thing I think is other than language portability is being able to reproduce these environments back in the browser. Like I said, one thing we focus on very heavily is if I can pull WebAssembly out of the browser, we like to be able to put it back in. We think that's a very important thing to be able to actually see what's going on, being able to debug, being able to understand and make confident updates to these systems. Yeah, so we're working on a couple things in this realm. We'd love contributors for, especially in the device interface and actually some of these abstractions. And we're not the only people working on this. There's a couple great posts out there as we've been working on this where Disney Plus actually uses this model to deliver out to all their clients, all their TV set boxes because they're trying to ship out hundreds of millions of different clients to different devices and they want to write the same code. And they're gonna be on different set top boxes. There's gonna be different capabilities for each of these. And so this was one of their major projects to actually run. And all their user space code runs in WebAssembly and they wrap around that to create this environment for those edge and embedded applications. And Amazon Prime's doing this with a few parts of their application, but not as extensively as how Disney Plus is doing it now. So I'm gonna show a quick video. Like I said, I will get my device flashback tonight. And the last slide will have some context. So I'd love to show that. Let's see which one. So I have a micro bit, had a micro bit, running, is this the right one? It pops up in the right spot. What are you doing VLC? Nope, not that one. That one. Another one's the code. So what we have here is this is the micro bit running the WebAssembly micro runtime. And what we've done is we've abstracted over the Bluetooth for it and moving buttons, we were starting to create a connect for game, but it is running. So it's WebAssembly micro runtime, then you have a tiny go application that is, and then the device interface there abstracts over the buttons, the LED display and the Bluetooth for networking. So that's the only ones we implemented here. The micro bit also has a gyroscope, but I think the V2 even has speakers on a microphone. The idea being is all of those get exposed up to, through something called WIT, and WIT by Gen, so that you can then go compile and create those applications with tiny go, assembly script, grain, any WebAssembly runtime out there. And importantly, we also have a network abstraction here so that I'm not sending a button press event, I'm updating the state of those LEDs local to the device. And the runtime that's actually running that WebAssembly takes care of all the information needed, and this is running up in Chrome. So I press those buttons and I'm mirroring the state in about 15, 20 lines of code that would have otherwise taken, I go bootstrap the network, I go bootstrap the buttons and operate the buttons, I have to then go send the button press event and then I have to go synchronize between the two sides. And so, actually, this is a good, in this case, all I'm dealing with, all I'm dealing with here is a board state, right? And I'm just updating values on that, runtime takes care of the rest. So I think that's where having these development kits that are runtime for WebAssembly for the client is gonna become more and more interesting and important as they mature. So really, what we're talking about here, let me pop this back on. And what I'm excited about is enabling, of course it does not wanna play nice now, there we go, enabling modular composable systems for real-time systems at the edge and in embedded environments. So thanks everyone. Like I said, I'm a C2C2 co-founder of Mycelial. Details are up there. I will be getting the actual physical demo going back up tonight on fresh hardware, depending on if I need to go pop by an electronic store or not. And that's it. I think we have a few minutes for questions. Michael Tannenbaum, my co-founder, I can get you in touch with him, too. Yeah, I don't get to answer any questions you have for that as well. That's one of the use cases we're sort of targeting with that state replication. Could you talk a bit about how, like, porting to different devices or like, say a new board gets made, how does that work as far as getting the runtime made up so that you could use the WebAssembly? Yeah, that's a great question. So when we face some of that. So the question is, say a new board comes out, a new architecture comes out, how do you end up porting to, port between systems and different architectures and different boards? And I think we're still trying to figure out the best way to go about a little bit of that. We've got the benefit in a lot of cases of we can set on top of the work done in the Zygon Rust embedded communities where there's often an architecture ready to go. When it comes to new peripheral devices, it ends up being a lot of spec sheets. We're looking at making that composable as well because I think one of the thinnest layer to actually go and add a new sensor, for example, is kind of the goal, right? And in a lot of cases, when you look at hardware shortages and everything else, you just really need a temperature sensor that can get you the temperature out to like milled degrees, right, Celsius. And so at this point it's reading some spec sheets because there's really just not an IDL for a lot of these just consumer grade devices and there's been a little bit of porting that. But we are looking and part of that web assembly device interface, and once we get it more up with love ideas on is how to kind of automate some of that process. When it comes to the run times themselves, this is where an interpreter becomes easier, right? Because all you need to do is take that interpreter and get it to that platform. And that's where, say, ZigCC comes in or LLVM comes in really nicely to be able to port to those. For those AOT and JIT environments, for example, Wall Zero, if I remember correctly, does JIT for AMD64 right now, but doesn't do it for ARM, right? And so at some point there, when they're writing out assembly instructions at the end of the day before the jump. And so there's a lot of porting work there. And I think right now for a speed and use case and deployability perspective we're really kind of preferring interpreters at the moment so that porting becomes a little bit easier. And I think right now if you look at it, you can support most of the reduced instruction set boards out there today. But for example, like RP2040 took a little bit of time to support when that came out with the Wasm3. And I don't know, but I think they still may be one of the only ones where you can compile down to that. So time and energy, I guess. The nice thing about the interpreter model though is once you have it for that environment and it can write a WebAssembly instruction, you can write it, right? You don't have to generate out machine code for the WebAssembly itself. Does that answer your question? Any other questions? Yes? Hi. Is there some way to evaluate the course of an execution, for example, the number of instructions for specific function or the maximum memory required for specific function? WebAssembly? Which is kind of, I think the main difference with EVPF. Fana? Yeah, could you repeat the first part of the question? Are you asking about the, yeah, could you repeat the first part, please? Yeah, so is there some way to evaluate the cost in time or memory usage of a specific code? So that's a great question. Is there a way to go evaluate the specific cost or the overhead of executing these instructions? Obviously it's gonna be a bit runtime dependent. One of the areas where WebAssembly falls down a little bit and today and needs some work around is debugging. It's a little, there's not as many tools as I would like, but there is a wasm to see. Michael, do you know what I'm talking about? Which one? Yeah, I'll usually try to go to that to try to get some idea. But right now, no, there's, I'm not aware of a really good way to profile and debug. And so there's just a little bit of trial and error, especially down like the WebAssembly micro runtime right now. Because the page size is only four kilobytes there instead of the 64 kilobyte page that you have in the other runtimes. And so it runs into some more interesting explosions that are a little harder to debug at the moment. Hopefully soon. There's some people who are really interested in that problem and working on that. If you have timing goals, whether they're hard real-time or just general responsiveness with both WebAssembly and with your framework, what kind of approaches do you recommend? Yeah, that's a great question. So if you have a harder soft real-time requirements and you have timing goals that you need to meet or QS that you need to make, how do you go about that in WebAssembly and in our framework? This gets into kind of a scheduling question we could talk about too later. But in a non-RTOS environment where you have full threads and everything, I think one of the better models I've seen, I think there's a new paper on it. I could find and send you, but the Beam, like the early VMs, Work Ceiling Scheduler and the Go Work Ceiling Scheduler are really great for ensuring those latency requirements. Obviously you're giving up some trade-off to get to, in those environments, actually, obviously, I shouldn't say that, but in those sorts of environments, you're giving up a trade of absolute latency for average latency across the entirety of the system. And so I think there is, there's a project I found that's inserting, it's actually rewriting the actual WebAssembly bundle to insert at IO points those yielding hooks to let the runtime decide. That's how I think we're thinking about it right now. I can find that project and send that to you, but it was a really interesting approach that was trying to basically jack in a Work Ceiling Scheduler into any running WebAssembly bundle. It didn't matter if the language supported it or not. And the intent there was to support runtime that wanted to be able to create more beam-style environments. I can't remember if Lunatic is using it or not, but I can find that for you. Yeah, there's no other questions. Thank you, everyone, very much. What do you think? Thank you. I wish...


Thank you. Thanks for having me. Thanks to the organizers for this being great for getting together such a great event for having me and being accommodating in various ways. So that's me. Yay in Bosta syndrome. I joined security quite late. I was doing a career in... I was going for a career in mathematics. I was originally going for a career in mathematics.   And by accident I ended up in insecurity, which I haven't regretted a single day since. But at the same time, when I discovered that these objects, these elliptic curves that I used to use in... they used to study as a mathematician, do play a big role in security in elliptic curve cartography. It was very exciting. So I don't do this in my day job, but I do study... I do like talking about elliptic curve cartography. And thanks for having... yeah, I hope you'll enjoy it. And I should actually add two more disclaimers. The first disclaimer is that something went wrong with the slides I realized. So they're supposed to appear in steps and they now appear the final version every time. I hope that's okay. And the second somewhat related disclaimer that I need to add is that I'm feeling not particularly great this morning and that affects my brain in all sorts of ways. I'll try and be as coherent as possible, but apologies in advance when I'm not. So three other disclaimers that I had put on the slides. First is that I am not a cartographer and I shouldn't pretend to be one. I've studied elliptic curves well enough that I could implement the algorithms, but I would make mistakes. I would make catastrophic mistakes and I'm definitely not qualifying to study other people's algorithms. And the second disclaimer is that if you want to be someone who studies elliptic curve cartography, you really have to study the math. You really have to spend probably years studying the algebra, the geometry, the cryptography. And that's not something that I can do in 45 minutes. So I will really hope that after this talk you have some high-level idea of what's going on in elliptic curve cartography, which you may come across in various ways in your day job or in your free time. But I don't want to pretend that this is actually something that you can use in practice straight away. And finally, my goal is really to explain things, to help you understand very broadly what's going on. And I find that more important than to be correct and to include all edge cases. So there are various places where I just skip a corner and sometimes saying a few things that are technically wrong. And if some of you have studied elliptic curve cartography, you probably know this and I apologize. I don't think they're wrong in a crucial way, but technically not everything is correct. So this is what elliptic curve looks like. This is every introduction to elliptic curve starts with this formula of y squared equals x cubed plus a times x plus b and the prime number p. And that's always the prime number p because this is cryptography and that's always prime numbers. That's true. I also find this particularly unhelpful. This doesn't give you any insight. The only thing, the only part of this that I think is worth understanding is that there's a choice to a mate. In fact, there are three choices to be made. Different a, different b, and different b give different elliptic curves. And some curves are far more suitable for elliptic curve cartography than others. So every elliptic curve algorithm always starts by choose a curve e. This I think is helpful. This is a picture of an elliptic curve. Now you've probably seen this. If you have ever read anything about elliptic curve, they include a picture like this. Sometimes they include a different picture which has two parts. Like there's kind of a circle like this thing on the left and then just a simple curve to the right. There's no difference between one and two curves. Not in a way that is relevant here. I find this less confusing. But if you read an article that used the other picture, that's just as fine. There's nothing wrong there. Now on this curve are points. A great many points in general, though a finite number of points or use it later on. The fact that there are finite number of points is because it's prime number p. Everything is over mod p. And that makes computers able to deal with it, because computers can only deal with finite sets. So here's an important construction. We take two points on the left of the curve called a p and q. And we take the line through p and q. And as it turns out, this line has a unique third crossing point. That's a property of elliptic curves. That's generally true. And that's very helpful. And that's because of the x cubed in the formula. Anyway, there is always such a third point. That's what's relevant. Now, from this point, we can take the vertical line through this point. Alternatively, we can take the mirror image in the horizontal axis which I've drawn there. And this gives another point.  I cannot stress enough that this is not supposed to make sense. I'm not explaining how you add p and q. I'm just saying, here's a construction, taking a point p and a point q. And this construction gives a point, a third point that I call or that we call p plus q. And that's it. And that's a related construction. And that's not with a single point p. And I'm trying to add p to itself. Now, you can't really take the line through p and p, because there are many of them. But it turns out, you can take the unique line through p that is tangent to the curve that touches the curve. And this line again has another unique second point of crossing. And we can take again the vertical line through it or the mirror image and find another crossing point.  And actually, I call it two times p. Again, not supposed to make sense, I'm just defining something. And we can combine these things. So I can add p and two times p. So again, take the line, take the mirror image. We've got two times p plus p, which I call three times p, as you probably would have guessed. And you can go on like this. You can get four times p and five times p, and et cetera. And computers can calculate these things. And you'll notice that going from p, two times p, three times p goes all over the place of the curve. There's no structure. This all over the place-ness word I just made up, that's crucial to lip-to-curve photography. As we'll see in a second. OK. Everything works like you'd expect. So it's not supposed to make sense in this addition, but it turns out it's not completely stupid either, because this works like normal addition in many ways. So p plus q equals q plus p. That's something that you can see if you think back to the construction. Less obvious, but something that you can figure out yourself at home if you feel like it. If you add two points and then add a third point, it doesn't matter in which order you do it. So you can add p plus q and then add r, or you can add q plus r and then add p. It's the same. And the same with integer multiplication. So you take a point p, you multiply it with m, and then with n. And you get n, but you can also multiply n and m first and then multiply it with p, et cetera. All the rules that you expect work. And the points in the lip-to-curve call what mathematicians, or form what mathematicians call an ambillian group. Yeah, OK. There are a few places where my slides will be a bit funny because of the PDF issues. And it's my mistake. So I apologize for that. You're supposed to not look beyond the first line. Just pretend that's only the first line. And just pretend that the first line says, the goal is given a point p, calculate n times p for some n. And I use n as a hundred as an example. And it takes 99 steps. Don't cheat. It takes 99 steps. Trust me.  Ninety-nine steps to get a hundred times p. Actually, no. As you can see, computers can do it faster. But I combine, cleverly combining, doubling, and adding points. So from p, you go to two times p. This is doubling.  You get 24 times p. And then you add 25 times p by adding p, and then doubling twice, you get a hundred times p. So that's eight steps to go from p to a hundred times p. You can probably do it a little bit faster even. But that's the kind of order of things. Which means that if you do this, say six times in a row, you go from p to a trillion times p in 48 steps. So the kind of numbers you see in lithographic photography, they're usually of the form a trillion times a trillion, that, or the need of the form of the order of magnitude. Which would take about a hundred steps. So computer can do that in a fraction of a second. That's cool. Now, the opposite is not true.  So I'm not saying here's n and here's p. I'm saying here's a point, say q, and q is n times p, and here's p. Find n.  Nothing significantly faster it can do. Which means that if my numbers are a trillion times a trillion big, then computer needs to do so many steps. And even for very large computers, at some point it's going to take millions of years. So this is called the discrete logarithm problem of elliptic curves. And that's the core of all elliptic curve cryptography. So probably the most important implementation, or at least the most well known implementation of elliptic curves, is the elliptic curve Diffie-Hellman key agreement protocol. So this cryptography, so we always have Alice and Bob. And Alice and Bob want to agree on a secret key over a public channel. And so Alice and Bob, you can think of it as Alice and Bob being here in this room, and they don't trust anyone else, but they want to find some kind of encryption key that they can use then, another algorithm to encrypt some messages. And I would agree in inverted commas, because they don't agree, they actually construct the curve as we'll see, the key as we'll see. So each has kind of half of the key, and together they make the full key. So we assume that Alice and Bob already know, and some are established, that they're talking to each other. There's no man in the middle, there's no Eve in the middle, or Mallory, who's pretending to be Bob and to be Alice. We assume they've already done that, and that's crucial, but there are ways to do that with certificates, for example. And it's helpful to think in practice that Alice is a web browser, and Bob is a web server. So first Alice and Bob agree on elliptic curve E and a point P on the curve. They do this publicly, they usually refer to some kind of standard where E and P are defined. Now Alice chooses a large random number A, trillion times a trillion, that sort of numbers, to keep that secret. Bob also chooses a large random number, lowercase B, also keeps that secret. Alice calculates A times P and sends this point to Bob. So Alice says, hey, Bob, here's a point A times P. And remember, anyone can see this, anyone knows P, anyone can see A times P, but thanks to this read, look, written problem, no one can actually find A. Likewise, Bob calculates B times P and sends this point B times P to Alice. And Alice then calculates, so Alice takes this B times P to the Bob center, keeps, uses her own secret number A, and calculates A times B times P. And Bob calculates B times A times P because Bob knows B, that's a secret number, and Alice sends them A times P. And as we've seen before, the order doesn't matter because that's how integer multiplication works. So this is the same point. So this point somehow converted to a number is, can be used as a secret key. This is used widely. This is how elliptic curve divvy helmet works. So here's a summary, because I'll refer to it a few times, so it's good to have a very general picture. Publicly known are a curve E and a point P on this curve, again referring to some standard. Alice uses a random number A, Bob a random number B, Alice sends A times P to Bob, Bob sends B times P to Alice, and the shared secret key is A times B times P, or B times A times P, which is the same. Sometimes you see not E, C, D, H, but E, C, D, H, E, which is the ephemeral version of elliptic curve divvy helmet, which means that Alice and Bob choose different A and B for each connection. So Alice and Bob can choose a fixed random number that they keep it to themselves, but they can also choose a different A and B in each connection. If they do that, that means they can't use A and B for authentication because I'll show you later, there's a signature algorithm where you can use your private key. They can't use it this way. The advantage of this is forward secrecy. Forward secrecy means that forward secrecy is best understood when something is not forward secret. So if Bob used the same B all the time for Alice, but for everyone else, Bob is a web server, so many connections, and someone knocks on Bob's door, uses a wrench, says, give me your number B, someone who has that number B can then decrypt any conversation they have seen in the past, because assuming they've recorded the A times B that Alice sent them, because they can multiply it with B that they now know and they can find the key, and they can decrypt everything else, which is not what you want. So this is why, despite the disadvantage, this is why elliptic curve divvy helmet is usually used in this ephemeral form. So let's see something in practice. You're not supposed to be able to read this, so don't worry. Many of you will recognize this. Hey, that's Wireshark. Yeah, so this is actually a Wireshark session of HTTPS connection between my laptop, this one here, and some random web server at nsac.io, which as it should use HTTPS. So my laptop says, okay, we're going to talk HTTPS, so let's agree on a cybersuite. And a cybersuite includes a number of algorithms, because in TLS there are actually a number of algorithms used for different things, but one of them is the key exchange algorithm. And my laptop, my fine fox, suggested 11 cybers, the first eight of which, the first eight most preferable ones, all in use elliptic curve divvy helmet and its ephemeral version. Okay, so server responds and says, okay, let's use this one, with the elliptic curve divvy helmet ephemeral, with rsa, as256, with the color quantum mode, and 3, 8, 4, 4 hashing, whatever that means. We care about elliptic curve divvy helmet. Now the client, my laptop, then send a certificate to, or checks a certificate to authenticate, that's not relevant here. This is again the server, the server says, okay, let's use a named curve, let's use a curve that's referred to in a standard, which I've implemented, and let's use the name curve, NIST curve, p256, that's a widely used curve that we'll actually see later. And my public key, which is my point, the b times p, has a length 65, 65 bytes, I told you by trillion times trillion, and probably more than that. And it looks like in hacks 0, 4, 9, 6, et cetera. And my browser then sends 8 times p, and from now on they can together, each of them can calculate the same encryption key, and I can't see what happens in my wire succession, because I haven't hacked my browser, so yeah, from then on everything is invisible. So this is how elliptic curve divvy helmet is widely used in practice. Okay, and crypto or key exchange is one important property, another important property of elliptic curve, sorry, another important use case of elliptic curve cryptography is digital signatures. And you've all seen digital signatures, and it shows, basically there are two ways digital signatures are used, one to authenticate an important piece of document, like okay, I've seen this document, I've had my signature, so I've seen it, I agree with it, but also, and for example, in an HTTPS, is to prove who you are, like okay, here's a random, some random data, I signed it with my key to show that it can only be me, not someone else. So I signed it with my private key, you can check, corresponds to my public key. I need a few definitions to explain this. So the first one is that I mentioned that on a curve, a curve has a finite number of points, which means in practice, if I start with p, and go two times p, and three times p, and four times p, just in theory, theoretically, you know, at some point I need to get back to p. And the order is the number of points you've met this way. So n times p is the last new point, and then n plus one times p is p again. So the order is the smallest n, but n plus one times p is p, it's the number of points in the loop. And that's actually easy to calculate, because, because mathematics, basically, you don't have to worry about really trying all the numbers, there are very easy ways, various easy ways to do this. Secondly, for the number k, and k is just a number, it's not a elliptic curve. I mean, I'll write k inverse to be the inverse of k in mod n, and this is order number. If you don't, if you're not familiar with these things, that's fine, don't worry about it, but it works like, like you, you expect one divided by k to work. The definition is that k times k inverse equals one mod n. So k times k inverse minus one is a, is a multiple of n. Anyway, don't, don't worry too much about it, it just works like an inverse. And finally, there are a number of cases here and later on where we need to turn p, the point, a point p into a number. The point p can be represented by a computer, and a computer can turn this into a number in a number of ways, different ways in different cases, but that's one of these details that I'll skip over. But I run, when I write p between vertical bars, pipes, like someone's called them, that's just p seen as an actual number, a number that you can add up, multiply, in the same way that you've known since primary school. Okay, so Alice has some data, and, and data is always assumed to be a large number m, and if data is larger, it's an even larger number than we hash it first. That's not very relevant here, but that always happens to your algorithms. We assume there is a large number m, and Alice wants to sign, so she wants to show, okay, I add at some point this number m, which is public, but I also had my private key, which only I know, and anyone can check my public key and then confirm that I have signed it, and no one else did. Okay, again, given our elliptic curve p and a point p of odd n on, on that curve, and Alice has a private key a, and the public key a times p, right, and p is public, p is known, but you can't calculate a, because it's a good problem. So the algorithm goes as follows. Alice uses a random number k between one and m, that's not particularly relevant, but a random large number. Alice then calculates k times the point p and sees it as a number, and she calls it r. She can do it easily, p is public, k is her random number, r doesn't give away anything about k, it just is a number. k times p is a point and we do it with a number. Then she can calculate m, which is the message, plus r times a, a is her secret number, divided by k, or times k inverse, and she calls it s. And I should make it clear, you know, she uses her a here, but the way it's used, the fact that k is unknown, means that someone who doesn't know k can't, in any way, can't find any information about a. Signature is then r, commas, the pair of numbers. What I always find counterintuitive, and I guess many find counterintuitive, that there isn't a unique signature. A different random number leads to a different, a different signature, a different pair of numbers, different r commas, and they're all fine. It matters that, what matters is that there are, out of the gazillion times gazillion possible signatures, there are only a trillion times a trillion possible right ones, which means that there's a probability of exactly zero that you ever, that the random combination is the right one. So, but there are multiple signatures and number k needs to be chosen randomly. Someone else, some Bob, tries to get this, this number, get this, this pair, can actually very easily confirm that this is, this is a value signature signed by Alice, based on the public k, a times p and these two numbers and the information about the curve that's public. I haven't written down how it works because it requires a few extra things out of the curve that are probably more confusing, but you can look it up. It's on Wikipedia, for example. Okay, so what if k isn't chosen randomly? What if Alice just misread the standard and thought, okay now I've got a nice random number k, I'll use it all the time. I mean saves me CPU power, I mean maybe Alice is, Alice is Sony or something. You know I think, hey I can save CPU power. I'll explain why Sony is relevant here in a sec. So, we get two signatures, two pairs of r and s, which are generated with the same k. And actually, if you look back how r is generated, r only depends on k and the point p, which is the same, which means that if k is the same, then r is the same in two signatures. So, only s is different. There is an s in an s prime because I use different messages. So, okay Alice signs two messages, m and m prime, this little accent is called the prime in math, and she signs them using the same random number. You can easily see that it's really primary school math. If you combine these two things, then m minus m prime, which are public, you know message are public, divided by s minus s prime, which again, there are signatures that are seen, that actually gives the number k, is reused number. And if you know k, then from the definition of s, you can easily solve a. So, if Alice only uses the same random number twice, you don't have to know which it is, but you can calculate the random number, you can calculate their private key, and everything else is disastrous from there. This was used in this way incorrectly by Sony in its PlayStation, I think people in 2013 it was, people were able to upload arbitrary code or something, which was normally is a signature check. Yeah, okay, if you know the private key, you can just sign it yourself. There's a slightly more subtle variant of this, which is if k is different, but not completely random, and actually in that case, takes a bit of time, but if ks are related, then you can still solve a Bitcoin wallet has made a mistake at some point. I think every crypto mistake ever has been made in Bitcoin wallets, probably the ones that we knew, we didn't know about. Let's see how we're doing for time. Okay, okay, I've mentioned random numbers a few times. Random numbers are very important in cryptography, elliptic cryptography is no exception. Computers unfortunately are not very good at randomness, that's kind of a feature of computers, they are predictable, I know it doesn't always feel like it when this morning I was doing something with my slides, but in general computers are predictable, they're very bad at random things, so they don't have enough randomness. They have some randomness, sometimes there's a random number generator device, like some using radioactive something, or you can measure how long it takes to store certain data on a hard drive, and then take the least significant numbers behind a decimal dot, and that also gives you some random numbers, but usually you don't have enough crew through randomness, so what a computer does is it uses a pseudo random number generator, which generate numbers that are random for all practical purposes, but are generated by an algorithm with a true random input, a true random seed. It works kind of like this in the picture, so you get through randomness, you input it in your algorithm, you get an internal state that's kept secret, and then based on that you output some random data, internal state fed back into the algorithm, and you get more data. I always imagine it's something like a machine that churns out random numbers while you turn some handle. Okay, one way to look at this grid-local problem, and I'm going to show you a random number generator to use elliptic curve cryptography, is that it looks that taking n, and then taking n times p, looks like a random operation, n times p taking the number, because it doesn't give away any information about n, so if you just see n times p that looks completely round, it's completely mangled up this number, you don't get any information about n, so this is, we can use this, so this is a very simple way, and ignore the red bit for a bit, so okay, there's a random c, they call it n zero, multiply with a fixed point p, p is given on a curve, and take the number, the vertical bar, the corresponding number, called n one, that's my output, so the green one is the internal state and the blue one is the output, get n two, etc. You can do this, this is easy, it can be done fast, you can't predict what's going on, unless you somehow see one of the outputs, say you somehow see n one, and that's not a bug, it's a feature in random number generators that sometimes the output is public, there are lots of ways in which random numbers are published in as part of an algorithm, like there's an algorithm that needs the server to send some random data, so we can assume that at some point someone has access to n one, that's a feature, but well if they do that, then they can kind of calculate n two by using the red thing, which is exactly the same as the arrow up there, I mean the vertical arrows, they don't do anything, just take the same number, so if you know the one output n one, then you know the whole internal state, you can predict all random numbers, so this doesn't work, thankfully we can vary a bit, because the problem here is, is that these vertical lines there, they're actually they're equal signs, you know, so you can go back, this is easily, but what if we use a second random number, sorry a second point on the curve q, and we multiply n one, sorry multiply this point q by n one first, then we get r one, this is an actual algorithm, so it generates 32 bytes numbers, actually throws away two bytes, the rest is the output, so this is where you can't go back, so if you see r one, if you see the 30 bytes of r one, you may be able to calculate the full output, but you can't go back, because that's the discrete logarithm problem, so okay you're stuck, seeing one output, which is a feature, doesn't give you any information about the elliptic, about the random number generator, about the internal state, so that's a good random number generator, yeah okay here, I just, I'm gonna explain things by hand, and I'll publish a slide later when I, when I fix them, so I apologize again for this, there's a fact, these points p and q are both on the curve, and there is actually, and that's some math there, there is a large number d, so the p equals d times q, okay cool, find that you can prove that there is such a number, but we also know from the discrete logarithm problem, you can't calculate the number, but imagine someone knows, someone knows this number d, someone has this number d, I don't know, maybe you're you're paragnostic and you see what number d is, okay, now is this someone first, and again I apologize for the mess, first they're able to calculate the whole output, not just r one, but the missing bit, the missing two bytes, it needs to check 65,000 points on whether one of them is a curve, and there's only one, and that's easy, computers can do it trivially, so we can assume the computer knows the whole output, not just 30 bytes, but the whole 32 bytes, and then they know r one, sorry, they know, yeah they know r one, they also know d, so they can take d times this number, which is, okay no sorry, I should say one more thing, so they know r one, so they know n one times q as a number, but actually find the corresponding point is also trivial, so okay, they know the point n one times q, see it doesn't give you n one, but they can multiply it with d, which they paragnostically know, so okay, d times n one times q, which is the same as n one times d times q, and n one times d times q is n one times p, so if you know this number d, you can go from r one to the next internal state to n two and to n three etc, so if you know d, then you've cracked this algorithm, so there's a ten million dollar question, and this would be nice if this appeared gradually, does anyone know d, and thankfully this is like all these algorithms there, they're public, you can look them up, it's a NIST algorithm, and NIST hopefully acknowledges and might boil and marry base from the National Security Agency for assistance in developing the recommendation, and I think that's a subtle way of saying they come up with these points p and q, and they chose the p and q in a way they knew d, so they basically, they choose a random point q on the curve, a random number d and another number p, and this is in the algorithm, and this is the famous dual EC DRBG backdoor to random number generator, dual refers to the two points ec, obviously it occurs, and DRBG is another way of saying pseudo-random number generator, it's the termistic random big generator, it's good to, there's a few things to say about this, firstly this has been used and there's a subtle reference here, RSA the maker of various crypto libraries, they use it as a default random number generator, allegedly after they got paid 10 million dollars by the NSA, which is probably a bad deal, secondly if you're not worried about the NSA, and you know you may be worried about the NSA, but in many cases individual cases you're not, and if you're using online banking, you know if the NSA wanted to they could just go to the bank and say what are you spending, what is this person spending your money on, so there's a lot of cases where we're not worried about the NSA, and in these cases this is a fine algorithm, it's completely secure, assuming NSA doesn't share this d with criminals, but okay it's fine, but actually for many other reasons it's a rubbish algorithm, it is slow, it's unnecessarily slow basically, there was no good reason to accept this, but the NSA using some money and some of its powers to do that, so there are two consequences of the RBC, which happened a few years ago, I think we can public in 2013 after Snowden leaked, people distrust any algorithm provided by the NSA, and I think that's wrong, not because I'm such a big fan of the NSA, but I think algorithms should be fine even if they're written by your arts enemy, you should just make sure that algorithm doesn't have backdoors, it's a bit like open source code, if you're supportive of open source software, you kind of expect you should be able to verify the software, you should trust the software regardless of who wrote it, I know it's a bit more complicated in practice, but yeah I think that just throwing away algorithms because the NSA designed them is not helpful, maybe makes people trust other parties more than they should, and NSA has some really good cryptographers, but what is a better trend is nothing of my sleep numbers, so numbers in elliptic curve cryptography in standards are often coming out of nowhere, so I printed a curve here, y squared equals x cubed minus 3x plus 41058 and then another 40 odd numbers, this is this curve P256 that we used, that I used to connect to an NSA.io, there's absolutely no reason to assume this is a backdoor, in fact we can be fair, everyone maybe except for extremely paranoid that people like Bruce Nyer, they all agree that this is not backdoor, but it's still bad practice, so people are moving now towards something called curve 25519 and this number refers to the prime number actually, but this number, this curve has parameters that you can explain, like why did I choose this parameters, I was looking for a number with these five properties and this is the smallest one that satisfies it, that's okay, that can't be backdoor, if everyone agrees these properties need to be satisfied and saying the smallest number that's not a backdoor, if you're saying well we're looking for these five properties and here's a very large number and trust this, you can check, then you should be wary, okay, almost done, do we have enough time still, okay, okay, there's a few attacks on elliptic curve calligraphy, this is one of the better known attacks on poor implementations, so ignore the blue and the red bit for a bit, this is again elliptic calligraphy helman, so it's a very long curve, E and a point P on the curve and then Alice and Bob choose random numbers A and B and they send A times B and B times B, but now we're in a situation where Bob is not using the ephemeral version, they're actually using a static V for all connections, which some algorithms, some implementations still do and there are, I think this advantage is outweigh the advantages, but in general I think this is, there are sometimes good reasons to do this, so Bob is a web server, talks to anyone and he's not suddenly not talking to some kind of Alice, but he's talking to Mallory and Mallory doesn't choose a random number A, Mallory chooses a point P of, sorry, a point Q of small order, say order five, which means that you go one times Q, two times Q, three times Q, four times Q, five times Q and then six times Q is Q again, so you keep going in circles, so there are only five possibilities for multiples of Q and he uses that and that's what she sends to Bob, Bob thinks this is some kind of A times P for some A, so Bob thinks okay, B times A times P, actually he's calculating B times Q and that's his, that he thinks that's the shared key, now there's two things to say about this, the first is this point is not even on the curve, there are, sometimes Bob, some poor implications that is don't check if a point sent to you by Alice or Mallory is on the curve and there are curves related to a fixed curve that don't give any problems, like if you do calculations you won't notice it, if you never check if a point is on the curve, the calculations work, you're just calculating it on a different curve without realizing, so the second thing to notice is that there are only few possibilities, only five in my example of B times Q which Bob is using as a private key, so Bob is encrypting some data with Mallory and Mallory can just check the five possibilities because she knows Q, she's sent Q to Bob and one of these five is correct, that doesn't give her B, but it gives her B mod five, she can find out whether B ends on a one over four or one over six or two or seven or three or eight, so she reduces the number of possibilities for B by a factor of five and she can continue this and know B is static, so you can choose another curve with another Q of order three and then seven and then eleven and she knows B mod a lot of prime numbers and there's something in a math called the Chinese remainder theorem which helps her find the original B, so if Bob doesn't check, doesn't check if points are on a curve you can attack it this way and it's actually used in practice, there's Java, I think Oracle library somewhere, there's quite a few libraries that don't check this, okay last thing, this is, so you know Diffie-Hellman, the curve Diffie-Hellman depends on the discrete localism problem, one way to see it you know this is all over the placeness, computers can't see structure when it's all over the placeness, but there is actually some structure, it's really just a circle, it just that it doesn't look like a circle because you go all the way over the curve and a trillion times, a trillion times, but there is some structure and quantum computers which are these new magical things that maybe we get at some point are able to see the structure, that's one way of feeling it and they can crack this algorithm relatively easily, so we need to find new algorithms if we're worried about quantum computers and people are already worried about this because sometimes government data is stored for a long time you know, if you store data for 30 years, you want to store it for 30 years, then you need to protect against computers that we have in 30 years, so people are already playing it, I don't know whether we'll get quantum computers, whether we'll get good ones ever and people are still not sure about that, but okay we may and there is a Diffie-Hellman variant that uses elliptic curve cryptography in a different way, so this is the general Diffie-Hellman and there's a standard version of Diffie-Hellman which is maybe one of the oldest public key algorithm so 40 years old, it's an elliptic curve Diffie-Hellman that we just thought, but in general there's a structure like an elliptic curve with integer multiplication in the way I defined it and a base element B a point and then okay this is A and B chosen randomly and A times B times B etc, so there's a more general algorithm, there is an elliptic curve variant that works post quantum computers, the structure here is the class of elliptic curves or a class of particular elliptic curve in fact for some irony it's a class of elliptic curves that are very unsuitable for normal elliptic curve cryptography but for some reason this class is very suitable for post quantum cryptography, integer multiplication is or multiplication is more than one curve into another curve and you can if you move from curve to another curve and then follow the same morphing and follow the same morphing you know if you get five times you multiply by five, I know I'm not explaining this really well, I'd almost say I mean yeah no I have to admit I do find this also confusing, I can follow the steps the algorithm which is again is on Wikipedia but that's that's about it but still this is morphing of curves into each other that's what you see in the base element is a fixed curve E, so what Alice and Bob do in this case is they morph E into two different curves which they kind of exchange and together they then combine this to get a new key which is their shared key curve is going to a number in some magical way and this this my number is shared the shared key okay that's almost done conclusion elliptic cryptography is hard and hard in inverted commas Chinese is hard if you don't if you never studied Chinese English is hard if you live in China never studied English but the cryptography like like a language requires years of studying and years of studying mathematics and it's easy to make mistakes and that's a weakness I think elliptic cryptography compared to say RSA algorithm it's just easier to make mistakes if people implement an algorithm understand them less well I understand them less well I find RSA easier less fun but it's easier we know how it's attacked I don't think the duality backdoor could have worked in some RSA like algorithm because it's easier to spot the reason why people still use elliptic cryptography despite this weakness and I can't emphasize enough this is a weakness this is not a strength you want your algorithms to be as well as possible you want you don't want an algorithm where three people in this room kind of understand what's going on you want to wonder everyone can just read it and follow it and check mistakes but okay yeah sometimes you need to compromise a bit elliptic curves there are enough people that understand it the keys you can use are a little shorter algorithms are faster that's just about worth it but don't go further than that and actually people are looking at ways to do post quantum elliptic curve cryptography in a way that I just explained super singular isogenese as they're called and and there was recently a paper by animal angley which is cryptographer from google and he actually pointed out that this very point this is a weakness that the fact that that this is a very hard algorithm it's a weakness it may have advantageous but actually maybe we can find an easier algorithm you slide the longer keys but maybe that's that's better um that's it I I hope it's somewhat understandable um that's my email address is my my twitter handle um yeah that there's probably some time for questions or or comments or anything I'm fine either way so