If you are out there, you don't want to be out there, you want to be in here because we're going to be talking about one of the most anticipated things of Monero just recently launched, Alpha.  So we've got an animal here, he's the man, he's the plan, he's the everything. If he dies first, crude. So let's give it up for him, he's going to be presenting to us Kovry, an introduction. Thank you. All right, everyone inside, here we go. All right, hope you like improv, you know, Miles Davis, Coltrane, go fashion improv. Okay, so Kovry, what is Kovry? Before I even wanted to get into that, I wanted to tackle the problem that we're trying to solve. Any physicists in the room? Any physicists? Oh, all right, cool, at least one. Okay, so is anyone familiar with anonymity? Okay, got a couple hands there for an enemy. And familiar enough with Monero to know that it's a privacy project? Okay, so let's see. I don't want to tell you what Kovry is until we establish the problem. But I'm also kind of trapped in my head after working on this all these years that I'm trying to also, you know, meet you halfway from the very beginning. Well, so we need to understand that basically everything is public. And I mean everything, I mean existence as you know it, okay? So I'll just start off four things I want to talk about. Let's see, privacy and anonymity never existed, it cannot exist and may never exist within the realm of unrealistic and quantum mechanics. I know that's kind of heavy or not, but it's important because it defines what we're doing. Secondly, I'd like to talk about identity because it all relates, it's all relative. And then third, I'd like to talk about what we are doing, like what we are really trying to do. I'm talking Monero to you're walking down the street to here we are now. And fourth, I'd like to present a solution to all of that. And then actually get forward to those actual stuff you can use right now before you leave. So I'd like to open with a question. So what is this? Anyone? You can just speak out. And it's not a fingerprint necessarily. I mean what is this? Like right there. Anyone? This isn't like a Plato's cave kind of retort. It's not like philosophical, it's like flat out what is that? This is clearly definable. It's essentially what we're basing our whole existence around at least when we're engineering things. Okay, so I'll call this, it's a point in space time. Now, how did you, how do you know that this is a point in space time? Sentience is not a requisite, you don't need to have consciousness to prove this. How do you know that this point is right here? Because you can see it, okay. But seeing isn't the same as measuring. We know observing is not the same as measuring. So how do you know? I mean how do you really know that this is a point in space time? It's really simple. It's because you are in space time right now. You are varied points in space time. You can measure this, you know, via whatever century inputs.  What does this have to do with anonymity? Well, the point is I'm trying to prove to you that there is no such thing as privacy in anonymity. It's just, it cannot happen. And we just proved it right now. Okay, so you're in space time, you're okay, so what do you mean by that? I don't know. What are you, no job? Okay, so let's try to cover, right? Let's try to, you know, cover this point in space time. I mean, can you prove that this point in space time still exists? Yes, you can. Indirectly or directly, you will, given enough time and energy, you can prove that something is here.  And essentially, you can, you can measure, eventually, you will measure with absolute certainty that something is in here and all its qualities, all its wonderful matter and what have you. So you say, okay, well, that's just like 20,000 layers of that.  Well, I mean, with absolute certainty, you know it's in space time because without it, nothing would exist there. And we'll, we'll go down that rabbit hole. But literally, you can't measure it. Given enough tools and time, you will be able to measure. Why am I wrapping this around? What is this? Well, that's the whole essence of layer drowning as you see in Tor, as you see in I2P and Covery. It is the constant of just wrapping things up with math and hoping someone doesn't, you know, figure it out, essentially. Okay. So, I mean, how about simple terms? Okay, here's something you can take and talk to your parents or, you know, whoever, loved ones.  Thank you. You close the door, right?  But I hate to break it to you are now public to everything within that room. See, it's all relative. You close that door. Okay, sure, sir, the door, you know, everyone outside the door may not be able to know you're there right now, but given enough time and energy, they can measure you. Heat dissipation, entropy, the thermodynamics, I mean, it is not some mystery, you will be found given enough time and energy. So you close the door, okay, you got some privacy. But then you go to use, you know, the facilities and you take off some layers of clothing, right? Because that was, you were private still, right? Well, now, you're public to the air, your skin is public to the air, and there is no such thing as privacy. I know that's a bold statement. And trust me, I've lost a lot of sleep, and I've really tried to prove myself wrong here. I want people to just get involved in discussion, prove this wrong. Physicists, everyone just, if you can solve any of, like, the inside of field equations without space-time, I mean, from Minkowski to Kairi, if you can just, anything, Andy, if you can prove any of this, please come to me and get involved. So privacy doesn't exist. Anonymity, so how do you define anonymity? You know, I, sorry, I should have asked you how do you define privacy, first of all? I kind of jumped the gun and assumed a lot of things. Does anyone have any other definitions of privacy that I didn't cover? No, okay. Now, anonymity, does anyone have definition? What is being anonymous? I mean, text book, it's to not have a name. But that's kind of silly because you just gave this a name. It's, because you can acknowledge, I won't say communicate. I'll say, because you can acknowledge this point in space-time, you've essentially assigned it an identity. So I'm sorry, you can't not have a name. So long as you are measurable and observable, you have an identity. So the concept of anonymity is just, it's not possible within the mechanics that we are engineering these systems right now to the best of our ability. Okay. Why does that matter? Well, again, that's the foundation of Alice and Bob. How do you know Bob? How do you know Alice? How do you, how can you prove Alice and Bob? So we'll talk about that too. So does everyone know who Alice and Bob is? Are, okay, I mean, no? Yes, no? Okay, so you know, Alice wants to talk to Bob. So I, and as we just discussed, so here are these two points. So what are, they want privacy, right? Well, we know privacy is not possible because they will be publicly talking to each other, essentially. But there are events in between these two points. They're called events. And well, what do you do?  Do you see how privacy and anonymity are not possible? You are relying on the very events in between these two points of space time in order to get your message across. But ironically, these events between these two points are the very thing that destroys your privacy and anonymity. Yeah, it's, it's a real mind twister. So what, what do we do? We, we attempt to emulate the anonymity and privacy. For example, with Tor and Covery I2P, you essentially send your message through various hops, using all kinds of encryption I'll talk about. And then eventually gets there, and Bob doesn't necessarily know where you are, and vice versa. But of course, given enough time and energy, that all that information is readily available because you exist within these models of mechanics. Yeah, so privacy and anonymity. Okay, so identity. Did I ask you what, how do you define identity? Did I ask that already? No. How, how does anyone define identity? And not necessarily, not necessarily mathematical identity where, you know, A equals B, which is in itself contentious because at the quantum level, you may as, it might not actually equal. And that's a whole other thing. But, so no thoughts and identity, huh? Being able to uniquely distinguish something from something else. Okay, yeah. But how do you do that? I mean, essentially the bottom line is it's all relative. Here we are back to the space time where it's literally everything is relative. It's driving me nuts because if we can't solve this problem, then we're never going to have privacy. Okay. So identity is, is relative, but more importantly, like, did you have a question? Yeah. How would you define that context though? But if it is measurable, then the relative perspective is that no matter how one system defines it, it still is, is relative so long as it can be measured. I don't know if that makes sense. But how do you prove that? But, but is that truly identity? And I would say yes, because like I just said, identity is relative. But I think what's more important is to understand how we use identity in that it, identity is also language. And language itself is also relative. So for example, when Alice wants to talk to Bob, they want to set up a Diffie-Hellman exchange, right? Generate a key pair. They're essentially creating a language for each other in a way that supposedly only these two points will be able to communicate. I don't know how huge that is, but I think it's, it's pretty big because it essentially defines all these, all these excuses for why we're doing this. It comes down to a lot of these simple basics. Language, for example. So I guess, I mean, why does this matter, right? Every day we're, we're trying to have these transactions. We're trying to be anonymous. But why? Can anyone tell me why? That's not like a textbook. You've heard this a thousand times. Why? Anyone know why? Why, why, why are we trying to do this? So this is what I believe. This is based on my preliminary, you know, studies of this, but I truly believe, and I think this is the direction we're going. We're essentially trying to bridge two points of space time into a single point of space time while retaining the qualities of those two separate points of space time, which I don't know if that's possible right now. Of course I would like to propose something soon, you know, in a few minutes, but think about it. Every time you go walk down the street, every time you go to eat, every time you go to hug someone, every time you open your eyes, every time you try to send a transaction, you're trying to connect with one other point and one other point only.   That's the hack right now. That's like the physics hack we're dealing with. But essentially that's what our ultimate goal is, I believe. Yes, Howard? That's fairly sure it doesn't cut it. I mean, like I've said, it's all measurable. I mean, it's not truly private. But again, that's all relative because when they're face to face with each other, they're still away from each other. There's always going to be those points of space time within the points. I'm not ignoring the infinity. And what I'm proposing is that's the solution to this problem because you're essentially describing the very same problem is there's space time and I, this is huge. There's two points of space time and face to face, whether that, I mean, it's always this coming together, you know, it's always this gravity. It's really annoying. But we are, we ultimately are seeking to, if I'm correct, the assumption was there, we're essentially trying to just avoid all of that space time so we can have that true connection while retaining our qualities. And I'm not talking this is something we're just going to whip up some code and do. I'm talking this is a long term endeavor, essentially describing what our purpose is. You know, we're obsessed with bringing these two points together. It's in everything. It's in your, it's this constant, the essence of movement, if you will. So that is what I see as being the problem, the ultimate problem. And that's why I, you know, I believe here is like this beginnings, the very beginnings of what could be the beginning of a new branch of physics, privacy physics. You know, if, if no one's talked about it, I would like to talk about it more. I'd like to initiate that idea. Privacy mechanics, you know, essentially if possible to solve the field equations without space time, that would be great. If not, let's, let's see what else we can do. It's very open-ended, but I like to just get that ball rolling. Tell your friends, get more people involved in the conversation. Okay. So any questions about that? You know, the physicists here might have a few comments too. Please, it's correct or anything. Anything, if you'd like. Yeah, exactly, exactly.  Yeah, I haven't heard anyone really talk about this. I mean, chaos theory aside and other things, I mean, I'm not like, involved enough to be like, hey, oh yeah, we've talked about this over lunch. So I don't know, we need more people involved in this. I've never really heard about, essentially, okay, sorry, I missed something. With the idea of privacy mechanics, we're essentially trying to do two things. Bridge, or not even bridge, sorry, excuse me, we're trying to bring two points of space time into one point while retaining the other points, if that even makes any sense, because if you try to do that and, you know, form something else that defeats the purpose. So we're trying to do that. We're also trying to exist while not existing. Folks, that is true privacy. If you can exist while not existing, but somehow, I mean, this is blowing my mind, right? I don't have the math with me right now, but I think those are at least two founding questions for something of a privacy mechanics. Did you have a question? My proposal? I mean, I don't have a solution. Not necessarily. I only propose those two questions. How they're achieved, I think we just, I don't know right now. I'd like more people to get involved. Anything more complicated than a pair of devices, which is fundamentally going to be a loss of model for business, but you reference field equations that match, which is a loss of model for business. I don't think it's a tracking problem to construct a loss of model that stood it up. Oh, I what? Attract? Did you say attract? Can you give them to Mike? Do you have a mic? I can't hear these people. I think my point is that I don't think it's unreasonable to rely upon an approximation considering our interpretation of physics, mathematics, is a model that is an approximation of physics and is necessarily so. And so proven otherwise. And I mean that's why we need more quantum physicists, for example. I mean to get small enough for you to start to say. No, no, no. I mean it was proven otherwise. That is what Gertl's work was. Any system more complicated than a certain, you know, more than simple arithmetic has paradoxes? Sure, paradoxes, but I mean is that a limiting factor, is it a defining factor for a potential new branch of physics? It's a defining factor for a branch of mathematics, which is a model of physics. It's unreasonable to expect since your work is probably going to rely on mathematics that it's also not going to be a perfect model of physics. Sure, sure. Okay, I'm not saying it's perfect. I'm just saying let's get the discussion going. I mean, health there by 30 years ago, there were iPads on Star Trek and now we have them, you know, for example. So let's get it going. Let's talk more. Let's try, hey, if we can solve this without having to divulge into other, you know, areas, sure. I love that, please. Okay, so that, that and that. Okay, so I'll briefly talk about, okay, so I said why we're doing that, but here's my little flare. I think it's ultimately true love, okay? It sounds corny, but I think this attempt to constantly try to connect with people and connect with these various points of space-time is essentially the essence of love. That's something to ponder to. I could elaborate that, and if you like, I don't know if this is the crowd who wants to hear that, but I would define it that way. Okay, so we have that, that, that and the proposal, great. Okay, wow, half hour. So how does that relate to Covary? So, so no one's really familiar with onion routing or garlic routing, anyone? Okay, jeez, I'd like my interaction. I don't have to explain everything that's already explained, but we have a garlic here, but we don't have a matroska doll, right? There's no doll, Diego? Okay, okay, so how about, does everyone know what a matroska doll is? One? Okay, how about I do a quick little image search so we're all on the same page? We're supposed to have a little thing I can demonstrate, but didn't happen. There we go, alright. So here we go. So back in the mid 90s, the Navy started researching, essentially created the onion router, version zero, long story short. A couple of versions later, version two, here we are with the tour project. Roger and Nick are heading that up with a whole team of people, and what they essentially said is, well we want point A to be anonymous to point B. So they, they said, oh well it's, it's, well, we can use that. So it's like an onion, you know, an onion has layers. Well, more accurately is actually this matroska doll, which they probably like thought of and said, oh no you can't say the R word, that's, that's a big no-no. But essentially this is the most, I believe, the most accurate way to describe that. So let's see. See how they, you know, the little one goes into this one, goes, so you can actually twist those off and you put one into the other, into the other, and you essentially, you have your message for that point B, you put it in, you wrap it up, you send it through various hops using public key encryption and they send it on down, send it on down, without being able to read the original message. It gets to point B and then point B just does it in reverse, sends it on back. So essentially it's encrypted all the way through. The points aren't able to discern what you're sending, unless they have enough time and energy, yes of course they can prove it, as we discussed. Now that's called like circuit, that's circuit routing, that's really straight forward three hops and you're there, but with Covry, and I need an assistant here, would the physicist like to come up and assist? Just standing here and you hold your arms out, okay. Okay, so I'll hold my hands out here and could you stand over there and do the same, like this. Okay, so I'll be Alice and Yubi Bob or vice versa, whatever you want and so Covry has inbound and outbound tunnels, so essentially I'll extend out and this will represent my out and then you extend in, actually you extend out this way, here we go, perfect, and then her inbound, these are her inbound tunnels, her arms extended in, arms extended out, outbound, my arms extended in, and Covry uses unidirectional tunnels, so we don't, I mean we complete a circuit, but technically with their unidirectional tunnels, where I send one message throughout various hops, all encrypted, goes to her inbound tunnel, also several hops encrypted, then she responds through this, your outbound tunnels, and comes through my inbound tunnels, that's in summary, you need directional tunnels, so thank you, very straightforward stuff, now the crypto used for both, oh that's for tunnels Algamol and AES 256, CBC, and session tags, technical things, for that, so okay we had those tunnels, I guess I shouldn't have sent you back, but essentially, so they say you want to send the message, right, well within that message, you send it through the various hops, and what's great about Covry and I2P is that it's a message based, fault tolerant, decentralized system, so you can send in fragments, if needed, and they are reassembled at various points, all encrypted, can be decrypted and sent off to the remaining hops, so it's a very, it's that, it's fault tolerant, but essentially, those are called garlic cloves, as we see here, various message, I2NP message types go into a clove, and you know, come there, so I mean, it's essentially, we're essentially layering upon layering upon layering, and we're asking, and here's the fault, here's the problem, I mean this is what breaks every overlay network, well at least Tor and I2P and Covry, is you're asking pretty please, pretty, pretty, pretty, pretty please, this first hop, please don't tell the second hop my IP address, don't give them any metadata, pretty please, so you can imagine the whole model is broken because of trust, because you can't really trust anything, so I hate to break it to you as much as, you know, everyone loves Tor, these things are just unresolved still, and that's what really got me going on this whole space-time, you know, circus, so, any questions on the Matroshka? Any questions? Okay, so we got that, that, and that, and I have a question for you, what do you want to know, if, exactly, do you have any like specific questions about Covry or about anonymity? No questions? Yes, Michael, how about, Michael, yes, did you have a question? I'm most interested to know how an application developer would, that's making an application independent of any transport, would implement Tor, Covry, maybe different types of protection, how they would use that? How they would use it? Sure, well once we get the API done by the end of this year, hopefully earlier, you would just hook into that as a C++ library, and we'll try to keep it real simple, you know, VSD style sockets, for example, you know, read, write, all that, and you would just say, I want to send to this address, and it, the Covry address, the base 32 encoded, and that's another thing, okay, destinations, the whole concept of destinations, all right, so you, just one tangent after another I can go on, okay, so you would essentially just hook into the library, but you would need to know the address you want to send to, correct? Do you know what address you would want to send to, off the top of your head? Network, kind of an agnostic application, you know how you can use Tor Proxy to use Tor with anything, with Firefox, or, and Firefox does not know what's using the Tor network, if you use Tor Proxy, is that something that you're thinking of? Well, essentially all Tor is doing is, it has, it's a Sox Proxy, so we have a Sox Proxy, if you want to use it, but because Covry and I2P, it's a network within the internet, I mean you're not going to be able to connect to Google or Facebook, unless they are hosting a I2P address, destination, you could use a Sox Proxy if you wanted something rough and generic, if you want more fine-tuning then you would use the API, which it's not out yet, but, yeah, and that's another thing with destinations, well before I go into that, with more hands, okay. Is there anything specific to Monero or blockchains that Covry's solving or is this totally generic solution, like another Tor or another I2P, like, or is there something blockchain-y about it? Oh, there's no, there's not nothing blockchained, nothing blockchain-y about it, but what's important to know is that this concept, well, there's Tor, you know, there's Tor, well, you know, it's like saying, well, there's Bitcoin, so why do you need any other coin? It's, we need more decentralization, we need more anonymity networks, we need more developers, otherwise it's centralized, so, but no, there's nothing extremely specific about Monero, other than them being a great project, spearheading privacy left and right, trustless privacy, this is crucial to creating this, so aside from that, no, there's no tie-in with the blockchain or anything like that. Um, so, help me understand, I understand how onion routing works, but what is the, like, specific use case that Covery is meant for that would be better than Tor, or you said it was based on I2P, right? Yes, the open specifications by I2P. So, are you essentially saying why not use Tor? Um, I'm asking, yeah, basically, like, it's, I'm, you're saying you want multiple networks for different use cases, right? Like, the network is stronger if you have more nodes operating in it. Sure, well, okay, I'm sorry, I don't understand. Can, can someone, could you rephrase it? Okay, Sean's, she, I can, we'll do that, um, okay, I mean, geez, it's, it's all online, okay, um, I'm thinking really technical, I'm sorry, I'm not like thinking, how do I say this? Um, okay, so Tor's, it's, first of all, they, they don't support UDP, so you have a whole transport just, just out of the equation. Um, secondly, it's a, uh, leech-based network, essentially. Everyone using it leeches off these relays that are heavily funded and, and can support a lot of bandwidths, so you have to ask, well, where does that money come from? Secondly, their whole directory authority model, in the specs it says itself, semi- trustless, but as we know, there's no such thing as semi, it's either you trust or you don't trust, and if you, if you're a fan of trusted setup, then you know, then you'll understand the, the dangers involved with that, it's essentially the same thing in, in an imiti-land. Um, with I2P you have, uh, a network database, it is truly a decentralized database that no one owns, it is, uh, passed around through various routers that are randomly selected based on a flood fill, uh, capability, for example, but no one owns these, there's no trust, it's up to you, you can decide a, which database you want to use, for example, you have that fine-tuned control, and it won't break the network, it won't, you don't have to go out of your way to do it, it's by default, essentially. Um, it's fault tolerant too, so if one tunnel, uh, goes, goes down, you have another, uh, a whole set to pull from, so your message will get to where it's going, um, and it will remain anonymous on both ends, for example. Tor, you always have that exit node, I mean, assuming we're not talking about hidden services, which is very similar, uh, you always have that exit node, which the website will always see as a point, and of course, from there it can be deduced where you are, given enough time and energy. So, did, did I answer? Sorry if I didn't. Yeah, that, that helps. And Covery is just based on I2P. Based on this, yeah, the specs, um, yes, essentially, so it is the same network, when you're using Covery, right now you are using the I2P network, you are blended in with every other router on that network. So, next. Yeah, so, um, you, your introduction was basically saying that, um, I mean, the way I understood it, you cannot solve, you can achieve real anonymity, right? Yes. And, um, so your solutions basically fall into the same realm because you have to work with, uh, what we have, right? Absolutely. Yeah, it's, it's a hack and, and what I'm saying is there's no piece of software on the planet that I know of, or that is relatively known, that is capable of achieving true privacy or anonymity. Unfortunately, Tor does never admit to that. None of these projects admit to actually providing 100% anonymity. But no one's really talks about the underlying problem. See, and the reason I'm bringing it up is because if we don't talk about this, we're just going to hand this off to our, you know, descendants and they'll be stuck with the same crap and they'll be going in circles and circles and circles until we have seven quintillion bit primes and, you know, 500 trillion ring signatures and et cetera, et cetera, trying to defeat this problem that cannot be defeated unless we can solve the removal of space time while somehow existing. I know it's like far fetching out there and whatnot, but that's just what I wanted to say, you know, as I hold it. Now, yeah, I just want to clarify that because it was a, yeah, generic statement and I want to understand where we're going. So, but talking about coverage, how is it, I mean, I understand trust less, but at some point you can still, like you said, with enough time and effort, trace back the, you know, the message or whatever you send it. Sure. I mean, and trust is relative, but as with any of these systems, you really have to have a lot of time and energy.  So it's all relative, but theoretically, this is what I'm talking about. Theoretically this is possible. Realistically, I mean, I would put my trust in this project and more than any other project, only because it's such an honest group of people who are not trying to screw each other or the world and we're really trying to, you know, apply hacks. We admit they're hacks. We're hacking our way, constantly developing, finding the best solutions at the time. And that's, I think, the best we can do at this point, in my opinion. Thank you. You're welcome. Oh, yes, one more question. I have answered this earlier. Oh, you may have answered this earlier, but why is this important for you to solve? I'm sorry, important to to solve this to solve this problem. Why is it important? Because we wouldn't have privacy or anonymity if we don't solve it. But more importantly, I mean, personally, I believe it's because we wouldn't achieve what we've been trying to achieve since day one, which is this coming together, this wanting to come together and actually come together. And I'll go and move. If I go too much off into that, but I'm sorry. Do you think you're getting closer to solving that problem? I think the fact that I'm talking about this and we're discussing it is a step closer.  Yes. So Covey understands in a different language, why do we need Covey in addition to itp? Do they have different applications or is Covey going to be better or? Okay, so I have to bite my tongue a lot when I got this is a tricky question, right? Because I have massive respect for the Java itp project. Simply put, we just we want to do things differently in a more efficient manner. I like the approach of less is more versus more is more. Does that answer your question? Because otherwise I can go into technical details. Well, they have different, essentially it is the same use case. Like you want to use the internet anonymously and privately, you just use it. But they have several APIs. If you've seen that web console, ZZZ, where's the camera? ZZZ, I mean, come on, man. Years and years and years we've been complaining about this web console, man. Please do something about it. So a web console, right? It's the only interface to this Java itp. And it's a nightmare for newcomers. So ultimately what I want to do is totally just get rid of all of this stuff. Like everything, all this technical stuff I want to speak about, I don't want to have to. Just like I don't want, it's an engineering thing. You don't want to talk about how do we build this building while we're in it. You know, this is how it's built. Now we're in it. I just want simple docs, simple application. You hook it in, poof, it's done, you don't think about it. If you want to know more, you read the specs and so on and so forth. And that is the complete opposite model of the other project. Essentially the same technology though. So would a good summary of it be a re-implantation of I2P in C++, fixing a lot of the stuff that is too complicated and you don't like, but it's completely interop with the network, right? Like it's going to be plug-in and if I want to run an I2P node I can run Calvary instead. Seamless. Yes. Do that. Gotcha. Although we may go in a different technical direction, that could possibly, you know, essentially hard fork the network because of various dramas and things that have come up. Lack of review and intentional lack of review and just pushing out of specs and then expecting us to just follow along. And I'm personally just tired of following along. But that's a whole another, we can talk more after the talk about that. Yes. So from what you're saying, it kind of sounds like Calvary is application agnostic and can be implemented into any other cryptocurrencies and not just Monero, which means that it's a semi-ultruristic project. He nailed it. Yes. Wow. That's cool. Monero's cool anyway. Thank you, Diego.  That's something like that. So, okay. God, well, she's there's so much to talk about. Wow, it's, we're here until five, right? Three, five, two, one. All right. So how about this? I'll just show you and then if questions come along, you know, and I can describe some of the details, the finer points. So I'm running the router right now. I disabled the console log so you're not really seeing anything. So, I'm assuming people are familiar with Tor Browser. Okay. So essentially all it does is it changes the, I mean it's, it does a lot of things, but one of them is with Firefox, their version of Firefox, it hooks into their SOX proxy, the Tor SOX proxy. So what I did is just went ahead and clicked this and went to the, you know, edit preferences. All right. Where is this? This is Icecat. Here we go. Settings. And essentially make the HTTP proxy, the, you know, the Covery instance port 4446. I set it to SSL even though we don't support SSL right now, but you don't need to because everything is end to end encrypted anyway. So that's a huge thing. Nothing to worry about there for the most part. I set up the FTP thing because that's another little trick. Sometimes your browser will do bad things. It's a, but anyway, if you're not using a SOX proxy, so here we go. Click that. And now we're going to check.covery.itp and I bet you an XMR that's going to say 503. Am I going to lose an XMR? Damn it, I might. Come on. I'm out. Okay, great. It works. So I'm out, but it's a win for everyone. Okay. So success. Welcome to the I2P network. Your local client destination. So that's something no one's asked yet. So we have IP addresses, right? You want to connect to Google or whatever. You have an IP address. They have an IP address. You resolve with DNS. Well, there is no DNS resolution within the I2P network. Names are canonical. They're locally defined. How I define check.covery.itp can be completely different. How you do it. It's extremely decentralized in that aspect. So unfortunately, like many problems with all these networks, we have side channels that we use. For example, address book subscription servers. But again, it's up to you to decide if you want to use someone's subscription. We ship a default subscription. So you know that check.covery.itp will go to a very specific destination. And here we go. Bay 64 encoded. SHA-256 hash of the destination. Now the identity here says keys. So it's algomall public pub key and then a DSA pub key plus a certificate of metadata that essentially forms your identity. And we don't have enough time to go into details.  So here's the base 64 encoded of that. And here's what's something you'll see a lot. It's essentially the B32 address. You go to blah, blah, blah, blah, blah, that B32.itp.  They have now longer addresses. Something ITP's been doing for a lot longer. ITP is essentially hidden services by default. I mean that is the network is the hidden service. That's the only way you can communicate. And here is the base 64 encoding of the full destination. This is something you'll see when creating your address book, if you will, your subscription. Very technical stuff. But this is how that works. So you know that you are using the network when you hook that up. So any questions on that, on this page? Yes. By default, if you have an address, okay, sorry, by default what? By default, you have this address and can people reach you through this address? So yeah, so here's, yes, here's the cool thing. All this data you're seeing here, this is identifying your identity through the SOX Procty. What's really cool is you can have many, many, many identities, theoretically. But this is the one that Check.Cover.ITP is communicating with. And if there's no name resolution to this, but it's, I mean, does that make sense? There could be, but the. If you registered. Yeah, but that's more for like a server tunnel. This is a client tunnel. That's something I should probably talk about, client and server tunnels. Did someone have another question? Okay, so we hooked that up through the SOX Procty. Now what Minero's gonna do is bypass the SOX Procty all together because it's clunky, it's slow, it's not effective, the error messages returned are pretty useless. I mean, theoretically they could have been using it for a while now, but they never wanted to implement a SOX Procty for various reasons, despite complaints. So, let's go into the config file. What is it? Okay. So here's the client, client tunnel list, essentially. Oh, there's that, I forgot to remove that. So these are default settings, right? Here's good ol' IRC2P. Now the ITP project started a little, I'm just gonna start, around the same time as Tor, but it started as the invisible IRC project. I mean, it was essentially an IRC network. It grew into what we see now, but this network is still around. It's what you use to use IRC over ITP. And we have these default client tunnels. And see how the destination it has, you know, IRC.IFLON.ITP, et cetera. Well, you need an address book to resolve that to, for example, you know, all this goody stuff here. But it's already set up, so you can use it. I don't have a client set up, but let's go ahead and do a quick check here. Oh, let's just send some random data. I'm connecting through the client tunnel, something that Monero will create on the fly, possibly per transaction, you can create a new client tunnel. It'll be completely transparent, and you won't even know it. I mean, that's why I don't wanna talk too much about it, because you just won't know, it'll just happen. And here we are. So we are connecting to IRC.IFLON.ITP via this client tunnel, and you can do the same. Look, we got SMTP set up. You can use Postman's mail service, for example. Now, let's go to the server tunnel. This is if you're going to go ahead and host a website, or, for example, Monero Node, for example. So you would, well, again, this would be automated, so you don't really need to know all this, but you just go ahead and uncheck. Here, I'll show you. These are three, yeah, I got- Is there a server in this program? Oh, no, no, no. It's funny. So, let's see, long story short, there are three IRC2P servers that are chosen at random, and these are servers that have been around, and this is after a person's name. It's like his handle for, I don't know, how long he's been around. Not that I know of, I certainly hope not. Though I do have- No, but if he's still, if he's watching this, his server's still broken. I told him, what, a year and a half ago, that it's leaking, I, you know, public, it's leaking his public IP address, and he's like, I intend to do that. So, I mean, it's one of many reasons why I want to, we want to move forward. So, I have this set up here. Oh, hello, Defcon. All right, so. Ha, da, da, da, da, da, da, da, da, da, all right. Where are we? There we go. So, look, here's a SSH server. A server tunnel. So, essentially, you need to tell the network, hey, here's my local destination. Here's why I want to be, you know, people to connect to. And here's the port. And here are the private public key pair, right there. And it comes through this server tunnel. Let's see if I can do this. I have it set up, I believe. All right, so. Uh, damn it, do I already have that in my history? I guess not. Okay, so, where is, ah. Oopsie, I'm not using TeamX there. So, the question is, well, okay, you created a server tunnel, what's your, how do you tell someone where your server is? Like, how do you tell them the address?  And here we go. We have the base 32 encoded address, and we have the base 64. Essentially, you want the base 32. So, let's see if we got that. And there we go. That is the address. You say, hey friend, connect to this address. And as we saw here, oh, where'd it go? As we saw here. You could replace the destination with an actual base 32 address or a resolvable address. But since I'm currently proxy chaining through Covary, I'm just gonna let it do it automatically. So, let's see. Let's turn this change. Where is it? And at, let's see what happens. Connection refused. Oh, that's not, what? Hey, at least it got refused. That's good. Yeah, so, let's try it again. Well, I might have changed the authorized keys. But essentially, you would be able to use the proxy chains, for example. You could proxy chains anything. To a I2P address, and it would work. Any questions on that so far? Okay, am I talking enough about Monero, like how it relates to Monero? Does it make sense yet, how it works with Monero?  Well, your IP address is known to that node and you have to hope that node doesn't know. So, perfect use case, by default, you will never have to worry about that. So long as you can connect to the internet and that you're not being censored at the packet level. Because then we would require more obfuscation with that. So, I hope I answered questions. Oh, yes. Versus what the performance is of this in strange of latency and other factors compared to TOR and previous I2P implementations. Okay, well, let's take a look. Here we are. Yeah. So, let me get out of Vim here. There we go, sorry. There we go. So, look at that, that is a pretty small memory footprint at the bottom. That's 26 megabytes RSS. I mean, you can tell, almost no... I mean, there's disk usage because we're writing and reading the network database, but right now it's trivial. This is a very small bandwidth router right now. Just this input right now, this instance is not very high bandwidth, but the stats are all right there. I mean, this is like 1.51% CPU. Like if you're looking at the Java router, no, this is massive, it's ridiculous. I don't know, it is what it is, but we don't like it. So, it's pretty small, pretty small footprint. And what's great is we can, you can eventually, once I finish my bandcaps branch, you can tweak how much bandwidth you wanna use. And of course, reflect on the amount of crypto use, et cetera, et cetera. Damn it, I'm sorry. Are you seeking to get this integrated with anything like tails? That's a good question. I mean, that's up to them. Essentially, it's agnostic. It can be used with anything that can hook into a C++ library. We'll get our marketing team on it. Okay, oh yes. Maybe I just don't really know a lot about it, but how does peer discovery work on, is it like relays, nodes, or is it basically, is it the same as ITP or did you change how ITP does it? Unfortunately, we're doing the same thing. Which again, we're left with the threat model of side channel. I mean, it's absolutely absurd that to get a view of the network, you need to connect to a reseed server that in itself has been scraping a very good view of the network. So you're relying on that view for it. So okay, let's say you mix it up and you pick from three or four servers, whatever.   I'm open to ideas. I think people have been beating their heads over this for a long time. But I mean, literally Tor's got, I can probably count equal issues that are just unavoidable, that are problems. But yeah, any other questions? Okay, no crypto questions? All right, well, oh yes. Can you wait for the mic please? Thank you. I came a little bit late, so please tell me to, Oh you missed the hole. Getting gooodle. Yeah, well just a little bit. But I heard a little bit about some things that can be done to make Covri more appropriate for more widespread usage, like to speed it up. Do you have any thoughts on anything people should be focusing on to do that? For widespread adoption? Yeah, just to make it more efficient, more reasonable to use. Use are friendly to use? No, no, no. Or just technically? The actual performance of the network and the performance of traffic on the network? Geez, I'm not sure how to answer that exactly in terms of engineering or? Well the problem with like resolving, let's say you want restricted routes for example. So you know that every hop, at least within your control is a high bandwidth.  Latency is not an issue. You're still stuck with Bob who's got his tunnel pool.  And I mean that's like the design of the network. We could, there are other possible networks in development, Hornet for example, it's something to look up. Yeah, I mean if you created. Oh okay, okay, okay. Well I mean it goes with anything if you're creating tons of key pairs and you're just generating, generating the more, the more hops you try to connect to the more tunnels you try to create too. I mean this is going to create more overhead. We use crypto plus plus, great library. No loader is a great guy. He's adamant about keeping things optimized and efficient. I mean the crypto is what it is. I'm not sure how to answer, I don't know. If I understand the question. Well the ITP consists of many protocols. It's a common misconception. I mean you have the transport layer, you have the message layer within the transports. I mean you have all this various encryption, Diffie Helman, El Gamal, AES, it just goes on and on. Shot 206, there's just a lot to do because these little garlic cloves are encrypted. Tunnels aren't encrypted. The transports, the sessions aren't encrypted. It's a lot of crypto and I mean how to solve that, I don't know, I mean we're talking about non-energy. Somehow using non-energy for our NNMB. Maybe they'll come with our privacy mechanics model I mentioned at the beginning. Non-energy, okay. I mean I'm not talking dark matter, but non-energy. Where did the physicist go? She's not here, she left. All right. Okay, any other questions? Yes. So with the physicist you explained that each direction was using a completely different channel and I was curious if that provides any advantage in terms of privacy or what's the reasoning? That's a good question, because it's still being debated. Does it provide more privacy? Does it provide less privacy? There's not enough research, but the research available proves that it's fine. Enough, I mean fine enough, I don't know, I really could argue for and against both and I could yap and yap and yap and talk and talk and talk, but, well Sean is prepared to some things too and I'm sure there'll be questions for him too. It's an ongoing thing. Essentially, we need more people, more developers, more input. You don't have to be a C++ developer. You don't have to be a lot of things. Just ask questions, get involved, and we'll do the best to see if there's something you can help out with. Yeah, Diego doesn't do anything, so he's doing great. He's doing a lot by doing a lot, but I do nothing. He do a lot, Diego. Okay, so yeah, any other questions? Yes, here, let me pull up the one slide I have. So I missed most of the beginning, I'm a PhD particle physicist, we can talk after. Yes, yes, thank you. Great. I was a bit bewildered by what I heard. So looking ahead, I don't know, maybe it's premature to ask something like this, but since each Monero node operator gets to choose for themselves whether their personal Monero client connects to the legacy internet or through Covery, would two clients connecting in two different ways, would two Monero nodes talk to each other directly, or could you have a situation, if say half the Monero nodes were running Covery and half were running on the legacy internet that you might have a great firewall sort of condition? That's a great question, and that's something Monero Moo and Fluffy Pony and others would have to actually answer because I have my opinions, but it's what they decide. So I don't know if I have an answer for you. It's available, it will be available to use, and I mean it's like my work's here, but I can only do so much. Sorry, I asked them. That made sense. Did you do any, I mean probably, but have you looked at the DevP2P, like the, so I like Ethereum or I've been doing a lot of Ethereum stuff, and Ethereum has its own kind of replacement for solving this type of problem called DevP2P. DevP2P, DEVP2P, it's just part of the Ethereum foundations, like big pool of open source stuff. Is it like Dandelion? I'm not familiar with Dandelion. Bitcoin's non-solution, sorry. Oh yeah, I mean if you haven't looked at it then that's fine. I was just wondering if there was any, like if you had any particular like challenges to that, which is why Covery is a need to create another solution to, but it's fine, like I get it. Well I mean at this point it's everyone's got their own, well I can do it better, I can do it better, and no one's actually solving the problem. I mean that was why I want, essentially that's why I wanted to open up with my opening statement. Everyone's got their approach, they think they got it, and it's just, there's one, you can laugh at it here, laugh at it there, or not laugh at it there, and we just keep doing it until we learn how to do it right, but yeah. Is this funded by the CIA? This project? Absolutely not. I'm completely funded. I mean you can do whatever research you want to me, FOIA, whatever, stalk me, follow me around, I don't, I mean it'd be creepy, but if you, no, I'm not, that's what's great about this project is entirely funded by Monero. The forum funding system for example, that's what I've been funded through, so I'm very glad to take that funding. No CIA, no alphabet agency, no government funding, not even the military, nothing, no research, nothing. It's all Monero. But in Monero, how would you know who's sending it? Yeah, so the question is, you should be stalking, given if you were here at the beginning, enough time and energy, that would all be certain. So, no other questions. Dang, I want to talk so much more, but I tend to ramble. So here we go, contact info, if you have any questions. And I guess that concludes my portion. I would like to hand it off to Sean, he has some things prepared. He'll provide actual useful applications, for Covery. So, thank you. Do you need the laptop? Thank you. It's not on here though. That's fine. Do you need the laptop? I just leave it here. Okay. My name is Sean Coughlin. I go by the hacker, Elias Sean Coughlin. So, nice to meet you. I am a software engineer. I work in industrial systems. And I focus most of my attention on security features and also I work on a number of other projects. I'm a continuing graduate student and work on applications of encryption for the use of effective engineering and the focus on the satisfaction of client dignity and business operations. I'm here to talk about Covery's techniques and applications. As an engineer, I decided to look into some of the latest IoT security protocols earlier, just about six months ago. And I came across I2P's implementation in Covery. Then I saw it was attached to Monero and so I decided to get involved in the Monero project. But I'm here because I really like Covery. I think it's fantastic. And this can really be the future of IoT devices. I'm gonna give a brief overview about the application history of I2P and Covery. These are all based on the original work which is called FreeNet which came out around 2000. It took some of the popular peer-to-peer networks that were run at like some of the file sharing stuff that was going on in the 90s. They were based on that and abstractly created a new communications layer, kind of replacing for TCP. And that started around 2000. Of course, in the 90s, DARPA was working on something similar that became the Onion Router Tor. And that was alphaed in about 2002.  And that uses their network layer from the P2P protocols and they added an extension to Onion Routing that they jokingly called garlic because they were looking for some other common vegetable that they could call it and so somebody came up with garlic. The differences that exist right now between Onion Routing and garlic is that, Onion Routs. They, in general, this is a lie but humor me. For one packet, it adds the layers of encryption for each hop in the known route. Meaning that every single item is there. It has to plot out the route from the source of the destination, adds in the encryption to each item and simply reduce like a merge COVID style until eventually it gets the end. The nice thing about that is the entire network is bi-directional. The receiver of a packet can then simply wrap it up and go right back where it was sent from. So it's basically TCP just with a little extra stuff on top. Garlic breaks that model and says, instead of actually taking one particularly known route, we're gonna take any packet of message you have, split it apart, shard it into smaller pieces and mix in combination a bunch of things and then get those as separate sub routes into different locations before you finally hit the destination. The problem with that is there's no way to go back to your original route. I2P is a simple unidirectional route and so in order to get back for the original sender you have to create a brand new channel all the way back. So it's a little bit more complicated and it adds extra, a little bit of extra slowness and things like that. But it really takes all of the indirection that Tor adds and simply adds an entirely new dimension and makes it so much harder to analyze everything. Even if you have like full network understanding it's still really, really hard to reproduce the actual original messages. So yeah, it's just so much better communications. It doesn't have any of the problems that Onion has which I'll go over in a moment. Now there's actually two separate implementations in job of the I2P. There's this original protocol that was called I2PD that existed and that's all I have to say about that but there's also a Java implementation that's the main ones out right now. The Java I2P implementation has the severe problem of using Java. It makes it easier to port to new systems but correspondingly requires a very large amount of resources. The memory requirements are about 128 megabytes by default but they can be reduced slightly. I'll go over some specs in those. It's not really ideal for embedded systems especially for very small microcontrollers. Though some Meteor Raspberry Pi boards can actually have a full function that's kind of the standard that we use in IoT to figure out if it's possible. Covery is C++ entirely and therefore surpasses the Java implementation in all possible performance metrics and it uses a boost library for compatibility. I'll go on that later. This along with other features makes Covery a much more suited for embedded systems and for other situations where performance is important. If for example, in the future if you're running a full node and say a Monero you're gonna have resource constraints. So if you have a choice between a Java I2P implementation if you have a choice between a Java I2P implementation and a C++ high performance process you definitely wanna take the high performance one. A bit about legality especially for business cases this is very important. In the United States no one has stood or sued for operating either a Tor Relay or an I2P router. However at the same time, importantly illegal usage has been tracked and responded to on both networks. Meaning it's not complete anarchy. There are ways of preventing people from causing damage and chaos in the network. Now specifically there's a problem with Tor Exit Relays. People have been interfered with harassed, sued although not arrested. They've had their resources taken from them and declared contraband. Even when the people were acting legally and in good faith. This has caused a lot of problems right now.  Covery does not implement an Exit Relay right now. So because of that there's actually less problems with I2P implementations like Covery. Just operating I know is perfectly legal in the United States so go ahead. There's no way you're gonna be harassed for that. Unfortunately internationally Tor is actually I just found this recently. Tor is explicitly illegal in Turkey. In fact all VPNs are. There's no information on I2P. I think they haven't actually implemented that law yet. This is a brand new law due to certain problems in that country. And also China blocks all access and to both I2P and Tor. They do that by takedown notices to the websites that have IP addresses that they track it to. And it's also, they also have a quasi-legal forbidden of all forms of ecrictions in certain areas. So business cases for use of either of these two protocols are gonna be limited because one of the most important markets simply can't be involved in that at all. And so if a device was manufactured in China that would be to use some of these protocols you're gonna have some issues. So you're probably gonna have to have some non-Chinese based manufacturing processes develop something that's going to be using one of these two products for an I2P device. However interestingly both Tor and I2P are pretty much legal everywhere else in the world. So you will have options. There's little no precedent on the industrial use of Tor or I2P. So this is basically a brand new area, Wild West, where innovation is gonna be dominant. And so what are the business use cases that we now can possibly have in this innovative space? For the non-embedded implementations of I2P like what we've seen so far. There's a couple of things that we can do right off the bat. Composite services, which is a way of saying let's just take what we already have and just start using that. You can use a combination of different protocols and any desktop or mobile devices you have right now. You can just simply start using I2P, whether the Java or the C++ implementations. It's possible right now, in fact, some companies do provide this service. Eapsites for file storage and even some DTD device and device services. But really the Eapsite for file services is something that has precedent. And Eapsites are I2P's implementation for a hidden service. You simply can go to a website and browse that as long as you know the name, the base 32 or the other directory name of that site. So it is possible to provide a service where you can actually store things on the deep net. This is popular in I believe some academic locations actually have this as a service. You can save your data and access it anywhere you want to later. Also interestingly, this is integratable right into existing apps, which is something that can be valuable. Let's say the Facebook corporation wanted to signify that it has deep commitment to the dignity of its customers and really wanted to have them have complete privacy. They said from this point forward, our app will now communicate over the internet using Covery so that everything's encrypted. We won't know your IP address. We swear we won't violate any of your privacy. They're not gonna do that, but hypothetically they could. They could simply turn it on right now and do that. Which is nice because there are some customers who might have that business case or they like to signal to their customers that they really are tolerant so they can just use that right now. Direct EAP sites other than for file storage. There really isn't much demand for that right now because in most locations, especially in the United States, this white market transactions and everything that needs to be kept above board, most businesses are required to keep some form of user relevant information, either for KYC, some of the exchanges, or just simply being able to collect receipts and other things. So let's say you used some EAP site like Amazon or something like that. They'd still have to get your address. So a lot of the privacy information, it doesn't really make much sense for them. It's gonna collect some important information from you to do that. However, if there were services available on EAP sites, it would signal very, be very well regarded by the privacy community and would really signal the services commitment to customer focus. If they wanted to allow the customer to say, we really wanna make sure that you are comfortable using our services. We inherently are showing, we don't wanna know where your contact information is. Here you go, you can use this service and that's also available immediately. Interestingly, because this is so new, there's some brand new features that nobody's really thought of before, like device to device, direct communications. It's even possible in the theory to have every particular device you have run as a separate router. So you can have things like mesh networks and you can even do webs of trust where you have known destination sign a particular base 32 address to say, okay, I trust this particular service so you can actually communicate correctly across these locations. There's no offline mode. ITP simply doesn't support that. But I think probably overall the best thing was kind of similar to what I was just saying, the support for ITP networks. Any customer right now has the ability to say, we support Tor and we support ITP. Now, Covery doesn't have these exit nodes that Tor does. But in the context of Tor, there's simply a way that or if we do, if Covery does have access to exit nodes in the future, it would be very similar to the way Tor has those. Websites currently have the ability to monitor for the use of Tor in ITP and many of them specifically decided to deny restrict access to the full features for the users that are registered from those IP addresses, those exit boxes. Some major websites are even threatening to do this well after they had previously fully supported in anonymous usage. Covery has no way to prevent this. But the easiest form of support for the Covery project is for websites to announce a policy that they will not prejudice users who choose to connect through Covery. While simple, this will signal their website owners trust and use of anonymizing technology and their commitment for fair access to all. And this is true especially for websites acting as an infrastructure of free and open source software or in their communications. This can be an important declaration of support for users rights. I bring this up specifically because there was a major website where you would get things on a major hub and it was purchased by this large software corporation recently. And so there's been some threats to remove access for people using Tor exit nodes, which is weird because that's probably the best case for people to communicate privately. That's a big threat. And after that actually happened, I decided to remove my support of that website because I simply didn't wanna deal with people changing their minds when they previously made a lot of stink about saying we support everyone. So I think there is gonna be a business case for that, that if you threaten to remove users, a lot of people are gonna revolt. On the embedded side, instead of just simply supporting what we currently have, the embedded side is really interesting. This is fascinating to me. Hypothetically, you can add new things for the device to device, but that's kind of similar to the way that the current thing goes. But for me, my focus is on IoT. And so I'd like to compare the services that we have with these. The IoT, the internet of things. Well, from a security perspective, it's also known as iOS, which is the internet of things. Yes, there's a lot of security problems. IoT was really fantastic in its original thought. It was a great way of connecting devices in an arbitrary, maybe even hostile environment to connect from a known device produced by a particular designer. Have it connect to the services provided by the designer. So you're actually purchasing a service, not a device. Most people who are very familiar with technology don't really like that much because it removes us as a factor. However, we're not most people here. Most people, they just want to have a service. They'd like to pay money and have something dedicated and work for them. And business cases can be well designed to satisfy that, but the people involved in designing these systems have to understand the threat that they provide by taking power away from their users. When you remove that power, you remove the dignity of them to actually be satisfied. It requires you as a designer to put a lot of faith in yourself and to understand the future and the threats that you're very modelled at providing for people will be satisfied. You're taking the privacy in your hands.  So I'd like to go over a couple of these IoT protocols that are very popular nowadays and discuss some of the limitations of them and also introduce why embedded cover is gonna be, I think, the best possible solution right now. So the first and most common protocol is known as HTTP. They're also RTSP and well, just plain old-fashioned FTP. No, not HTTPS, not FTPS, and the most popular one is just HTTP. Most devices just send clear text communication right over the internet. I'm responsible for maintaining some of those and that's all I have to say about that. UPNP was actually, a thought was actually putting encryption into that and allowing dynamic port openings and just dynamic communications over the internet. They created a couple of protocols called device protection and device security service. Unfortunately, those have been shown to have severe security flaws right from the design. So for briefly, that was thought to be a replacement for some of the other protocols, but it's been pretty much completely abandoned. It's useful just for opening ports, but not a whole lot else. The most popular right now, maybe even surpasses HTTP on new devices. TLS, the transport layer security, which is a new version of SSL. This was designed with websites in mind. It works fantastic for human interaction systems when there's some human that makes his decision. Most users have been well trained to look for that little logo in the upper left-hand corner of their browser to let them know that the website they're going to is trustworthy, that there's some certificate authority that has said this website is who they say they are. A lot of phishing has been trying to get people to click on links they don't trust, so it's a lot of IT work to make sure people are trained, don't do that. That's great for websites where you have a human decision being made, because ultimately, if some user just doesn't understand and makes a mistake, they are the ones who pay. It's their responsibility. It's their decision, it's their initiative. When you're dealing with IoT devices, the customer does not have that decision. You're making that decision for them. And so if you're going to be making something, you gotta make sure you put everything, you design your protocol around something that doesn't allow user override. TLS is designed around certificate authorities. It's great because it allows designers to have their own internal certificate authority, and usually they send out X519 certificates, which are generally okay. Not the best, but they work. And there's even new extensions of TLS to make them more IoT compatible, like TLS 1.3. It removes some of the work required and reduces some of the known attack vectors. And there's even things like certificate pinning that makes it very easy for IoT developers to just simply go in and say, okay, just here's the certificate, trust it for your lifetime. There are a lot of problems with design though. Certificate pinning is vulnerable on the first use. In other words, if the device gets reset or flashed the first time somebody puts an assert on, they have complete control over everything. And that's one of the major ways of, if you go over the IoT village, you see that pretty much the first thing anybody does on a device. And even worse, if a certificate authority is actually compromised, every device is compromised too. It's the one control, get password access to that, it's over, hackers have everything. And even unfortunately, TLS assumes TCP communications. So you have to have full bi-directional access. There's no data, no datagrams, no async, nothing. You gotta be connected online every time you use that. And most people don't have Wi-Fi connected all the time. So they're gonna have to walk around on devices that are disconnected for a very long period of time. Which of course means everything's running old firmware with known vulnerabilities and everything. So meh, that just causes more nightmares. The new TLS reduces a layer, but it still has like three round duplex real-time communication. So you have to have something that's fast dedicated low latency on your connection. So it's really hard to use like low speed communication layers which is just more of a mess, especially if you're downloading like new firmware, which might be pretty big. You gotta have a fast one. The problem is with internal certificate authorities. They're actually pretty complicated. What's happening nowadays is that most IoT developers are actually buying outside vendors. They sell modules as a service. They're third-party services, but they have the... This is interesting. They generally do have the predictability and flexibility that corporate clients prefer over costly dedicated development programmer teams. And the nice thing about a module vendor is if they violate your security, you can sue them and blame them. Hey, it wasn't us. Look at these guys, look at those guys over there. And that's been a lot. Most of the IoT leaks and everything are actually people just saying, well, it wasn't our fault. It was our vendor, so you gotta blame them, which is nice from a legal perspective, but not really from a customer perspective. And even then, the entire use of the third party decreases the trust model. As there are ever more third parties and the third parties buying more third parties, everybody has access to your data along that chain. Even if they promise they don't, there's always some override where they can't get everything. Oh, if the certificate authority expires, which some of these actually do, I've seen them, they have expirations in them, then you got brick devices. If the certificate authority is compromised or must be reset, then you have brick devices. And oh, some of the protocols for IoT are actually plain text by default, like MQTT, the most popular protocol. That's all plain text. There is no security built into that, so. Meh. A couple of examples that are going on right now, you probably have heard about these already. Amazon Web Services, they have an IoT branch that supports TLS in their own version of MQTT. They're the only one that, they're the first group that allows MQTT to have an encrypted communication right off the bat. And they even have these things called IAM roles where you can go in and say, I want this device to have this communication capacity. This is great and it's convenient, but it really requires you to be embedded with Amazon the entire way from the device manufacturer all the way through use. So if they ever change anything, you're always trusting Amazon's service. They have this just-in-time registration where you can say, I want to take my old IoT device and start using it now. But you're still going through AWS. Oh, and there's a brand, well, not brand new, but it's a relatively newcomer called Datagram TLS, which doesn't use TCP. It's lightweight and it's fast and everything, but it has a lot of known vulnerabilities. So if anybody has a DTLS device, go bring it over to the OT hacking village and watch and cry. There's also this other one that I was filing a while back called HPKP. It's known as HTTP public key pinning, meaning that you can really guarantee that the device, once a firmware device is burned in, is guaranteed to connect to only the server. The problem is it's dead. Netflix killed, or no, Firefox killed it. So that's done. It doesn't exist anymore. A lot of people were developing on that and they just had to switch immediately. There is this other protocol called SASL, the simple authentication and security layer, which is a really nice way of abstracting your LDAP or your security protocols. It's the basis of LDAP. So if you ever use LDAP, you use SASL right out of the box. It's really flexible, which is nice. Unfortunately, it has extremely heavy restrictions on the communications allowed, so it's not useful for IoT. There is an implementation called XMPP, which has been kind of like the eight girl of 2018. It has a couple of protocols called provisioning and discovery, which are very similar to the way ITP works. It also uses globally unique addresses like the base 32 address in ITP. It's modular, which is very nice for small devices. It actually runs in Cortex M0s. Has very small memory footprint. And it's also just kind of considered the coolest thing out right now, except it still requires TLS and SASL. And this is the weirdest thing. It actually was designed for text messages, so there's no such thing as binary data. You have to encrypt or encode everything in base 64 in mind format to do anything. So if you have anything, any binary data like your firmware, you're gonna add what, 25 or 33% off the bat by default. So you're just adding more and more data on there. There really is no compression to think of. So great in theory, but yeah, just not doing everything right. And also there's some brand new communicate. We actually just heard about that before, like things like CJDNS, Tink, Crust. There's numerous other layers that are being added on. They're beginning work and creating a new super network above TCP as a way of encrypting communications. Many of these use classical patterns such as pseudonymous identification, which are known to have severe flaws that onion and garlic routing was specifically designed to address. But on the security versus speed scale, these tend to have pretty good implementations on the speed side for IoT devices that really want high speed, say a smart television that wants to connect over unknown networks, the tragedy networks. It's actually a pretty good path to take because you want speed more than anything. But for say, industrial control systems that have all the security problems, they're willing to sacrifice speed in order to gain more security. In general, the IoT devices that have security problems have latency built in, so they don't really need speed. But the newer systems, CJDNS, really it actually has a significant increase in performance over TLS. So that's something to look into if you're interested in that. Most of these projects are so new, they don't actually have any performance metrics, so I can't compare how fast they are compared to Covri, so you're guessing as good as mine. Also, there's a brand new one called TLSSRP, which is a way of making TLS much more IoT compatible, but it's still a work in progress right now. So there's no metrics, no anything. There's a lot of talk, the people who are really big into XMPP this year are not talking about TLSSRP because it's just kind of really cool. It's, I think, the best competitor to Covri in the embedded IoT sphere over the next couple of years. All right, now, those are all the protocols that nobody is probably ever gonna use ever again or hear about either after this, so let's go talk about Tor, the onion router. Performance-wise, well, you know about the onion protocol, how it wraps everything up like a Marsh COVID doll, and how that differs from Covri and I2P. Performance metrics, Tor, by default, runs on Linux at about 512 megs minimum, which is a pretty huge impact, it's pretty significant. Now, there are implementations that can be brought down to very small amounts, like there is, for TP-Link routers in OpenWRT, you actually only need about 64 megs of RAM for running a full Tor router, which is impressive, but still that's a lot more than, say, smaller devices like Core M series can run. Tor has this new system that was created just recently called the Authenticated Hidden Service, or onion authorization. There was a demo that was released about two years ago when the original thought was that they could actually implement this. It was about home security, so you can have all of your cameras, all of your baby monitoring systems hooked up through Tor automatically so you couldn't have some of the problems like weirdos in the internet breaking into your baby monitoring systems, things like that. So it actually works fairly well. You're able to get a cookie password and log in and be able to access these devices right through Tor as though you were communicating over the open internet. There's no way to probe for services from the outside unless you have a cookie. And the API is called Hidden Service Authentication Client. Current implementations are based on what's called the basic mode, which is very limited. There's only 16 devices internally. There's another protocol called Stealth Mode, which is very difficult to work with in impossible scale. Also, cookies have 128-bit security or a bit encryption, which is nice, but a little bit less than you expect nowadays. Generally, authenticated hidden services are a good idea, but they don't really have what IoT needs, especially in the memory aspect, which finally brings us down to embedded Covery in something I'm really excited for. On an open WRT router, this has about 21.4 megabyte memory profile, which is just good enough for some very small devices. Maybe not the Cortex-M series, but definitely the A-Series and anything really small, anything slightly bigger than the M-Series. Again, I'm probably lying right now, but I think this is kind of interesting. Covery ITP has a lot of flexibility in that let's say you want a certificate authority with a X509 certificate. You can throw that in as your destination encryption. Want a completely separate protocol?  Add 255.19, use that, use whatever you want. Anything works. It's scalable, and this is interesting. Let's say you have your EPSI, your destination server, hooked up with one port that's receiving multiple destinations. You do a receive on a port. You can tell how many, or not only have multiple destinations dedicated to a particular port on your box, you can also have, let's say, once you do a receive, you can tell which destination it came from. So you can tell exactly which client was requesting which destination at a given time, and since you can create any arbitrary number of destinations at a time, you can just scale up to whatever you want to. How many ports are allowed in a computer, 65K? How many destinations are allowed for a port? I don't know, 65K, so you can have what, four billion destinations on one simple box? So you can support four billion separate devices connecting to you, or four billion separate services. That's pretty good scale as far as I'm concerned. Nothing else even comes close to that. Oh, interesting this too, basically you can have your completely automated anti-DOS attack. Let's say you have X devices and you, a thousand devices, and you have 100 destinations that you make up, just separate numbers that you connect to for the same thing. So you have 10 devices per destination.   All those go to DevNow. All that spam just disappears entirely. All the other customers work, and those 10 customers that were hard bound to that one particular destination, well they'll be offline temporarily. You can bring them back one ever. So that's an automatic anti-DOS without having to shift servers or anything. Just turn off the destination in your router, you're done. Other ideas you can go with. Let's say every version has a separate destination. The old destinations, instead of responding with anything, you just say, here's your upgrade, just upgrade your firmware, done. So no matter how old it is, it just automatically gets upgraded every time. And they get a new destination every time. Or you can even bring it as far as one destination per customer device. So you know exactly which device itself is coming. You don't need a serial number, you just see the request coming in and you're good. All destinations can be, well they can be hidden for the use cases. Somebody can tell whether they exist by the route actually getting through, but you can't tell what they're used for. This is really cool because this allows for a lot of new ideas that nobody's had before. Like, Covery's not just the best IoT communications protocol I've ever seen. But it actually allows entirely new methods of communication. It's possible now to prove your device is security. You can actually prove your device is secure. You no longer have to say trust me. In the case of say like a hardware manufacturer, we already have a lot of situations where you have secure elements built in. Let's say your secure element generates a destination keys. So therefore only a secure element has a private key. Then you can publish a base 64 public key version of that and have that as your destination point. Release your secure element source code as open source, have that publish its own hash. You have a way of now proving no one can possibly get access to your IoT devices private key. Even the people who designed it. This allows for really cool things because it's very similar to the way hardware wallets work. How about a hardware wallet that actually sends out its own transactions? Just sends them out. You don't need to connect to a device. Just go. Sends it out to whatever you can connect to. Eventually connects to a router and sends. In Monero, in pretty much all blockchains, all transactions are idempotent. I mean you can just keep sending the same transaction over and over and over and get there eventually. Just wait for your customer to let you know whether or not it happened or you can have something else monitoring the blockchain to see whether or not that particular transaction went through. But you don't need a, you actually don't need any way of connecting your hardware device. It actually keeps it open. Of course, it will have to, you have to get through places to update it with the current blockchain so that you know it's actually done. But maybe Cobra can get through that too. But yeah, that's a great way of actually sending device to device hardware identified transactions or just anonymous device to device communications like a human communication mesh where you can have people send messages or transactions to each other without connecting to the internet at all. Simply have each device acting as a router where everybody if you get in communications with each other or even just have it automatic over the air updates. As you walk between different locations you can have everything communicate. You'll never know where the information came from only that it got to wherever it needed to get to. Also D2ALG meaning you can have like a cloud based system using that very same thing. Have a device that's disconnected and simply sends data up to the cloud. How about a Fitbit device? I can't update my Fitbit unless I have a device that's communicating to the internet. Why not just have it asynchronously update everything through a Cobra router and have that eventually get updated then it can get sent there. So you don't need to have a constant web access for your IoT devices. It simply gets updated automatically whenever it needs to. There's a lot more innovative ideas that can happen now because this is just fun. All the rules that could eventually were in place are not broken. You can do so much more that there's really a lot of things that can happen that I don't know about. This is really a joy because IoT has usually been a problem recently. It's been getting bad press. There's a lot of things you can't do to maintain security. This breaks a lot of those rules. You can now go and do things that you always wanted to do without any security models. So yeah, this is a pleasure. Oh and I'd like to go over building the Covery, building Covery is embedded. We do have an Android build but as far as getting it to actually work as an embedded system, that's to be determined. I have a little bit of problems with that. But that should be out very soon. So yes, I really think Covery is the best IoT protocol ever invented and it gets back to where it always was supposed to be. All right, thank you, Sean. Did we have any questions for Sean here at the end about anything that he's talked about? No? Oh, we got one in the back. Okay, okay, hold on, I'm gonna be on my way there. You know how much walk you can do in Vegas? Okay, my leg's hurt. Let's go. Hi, thanks for your talk, Sean. I was wondering if you'd have any experience or any luck getting it to run on any other embedded ARM devices, even though the Android build is still has some kinks to work out. The numbers that I had on there was, it was actually about, I think it was like 30 megs in total. So that wasn't that bad but I didn't do a full test on actually getting a lot of connections to the internet. I just ran some simple tests like unit tests. But once that's available, I'd be able to publish all the information on that. Plus there's probably some other embedded links I could just remove. It's probably extra resources so it's gonna be smaller than that once I get that running. If it gets down to maybe 12 megs or less, that's available on even the smallest Cortex-M devices. So that'd be really nice. If there is some research into minimal implementation, that'd be really worth the effort because that will make pretty much any device, any IoT device available plug and play right into this. To shrink the binary. Oh, shrinking the binary. Oh yeah, shrinking the binary is nice but also just the general use of memory. The less memory use is possible, the better. There's certain things you could do to say optimize the memory access, keep everything to a really low profile. Some of the IoT devices have very small memory like four megs still. You still have the SOCs or at least it's just four megs in them. Those are specialty items. You usually can have a lot more than that. But the less is more, as an animal said, so yeah. Thanks. What do you think are going to be the major roadblocks in people adopting Covri for these sorts of applications that you're talking about on a large scale? The road, the major roadblock against implementation right now is the lack of any history. There's nobody's done this before. And especially when it comes to legality, some people just automatically assume anything to deal with Tor or ITP is automatically just for those hacker guys. And they do, yeah, the scary implementation or the scary suggestions. If there is a successful implementation that works in a really tough situation, something that gains attention, that could be very valuable. And so one of the things I want to do is actually implement this in a new direction, in a new project that could bring about a lot of attention and let people know. Some of the major questions so far are always about, well, if Monero is the only system that actually uses Covri, then won't everybody be able to tell that everything that's going on in Covri is Monero only? Won't they tell that you're a person who's involved in mining or sending transactions because you use Covri? So if there is some other application out there that uses something else, you'll at least begin to have what's called the plausible deniability issue, where you can say, well, I could be doing this other thing. I could be birdwatching and sending pictures of cats on the internet back and forth or something like that. So until we have a good environment where we have multiple use cases, that attitude is still gonna be there. This is basically the same thing that the internet was back in the mid-90s. Everybody thought it was for those weirdo hackers. They're the ones who send text messages back and forth. Real people always use fax machines or something. So once that attitude is broken, just simply due to precedent, then this will be more stable. IoT devices tend to be more conservative, which is why the security model threats have been really racking everybody together. Generally the same HTTP model has been around for basically 20 years. That's finally broken now that you're using at least TLS, but simple, clear text transactions have existed for a very long time. And it's only this constant push to say, hey, you gotta be responsible for your actions that have lifted people in the IoT world out from using that to put any encryption in there. So it has to be precedent, and really there has to be push to. This is as far as I'm concerned, it's a business model. You can signal to people the fact that you are providing trusted computing. You are signaling to everyone that, hey, I don't know who you are and we have a contract. We're gonna make sure that I don't have the information and that's part of the business process that I provide for you. It might cost you more money as a service to get what I'm offering, but I can guarantee you that you are not the product. You are the customer. I'm not gonna resell your information out to third parties and target advertising to you. All right, thank you, Anonimal and Sean for your guys' presentation on Covery. It's something that the whole Monero community is talking about and excited about. Alpha Release just came out and hopefully will be integrating to the Monero testnet before the end of the year. Just the testnet, just the testnet. Thank you so much, you can take this badge also.