 We're from a project called NIM, and we're going to be talking about privacy and blockchains and decentralized systems and distributed systems today, and a little bit about the internet and sort of more general systems outside of blockchains, and we're a project that's basically about privacy. The kinds of things we're going to talk about today, why are we doing this, what are the things that we're interested in, what kind of problems we're interested in solving, creating a quick definition of privacy, and we're going to talk about the two core technologies that we are working on. One of them is called the MixNet, which is a kind of better-than-tor way of anonymizing your internet traffic, and the second one is decentralized credentials, so that's kind of like, the quickest way I've ever tried to figure out to explain it to people is something like a decentralized OOF, but it's actually much more powerful than that, so you can actually use it to anonymize pretty much any cryptocurrency transaction or blockchain transaction using anonymizing claims, which I'll explain in great detail in just a moment. Then we'll do a quick demo, and then we have a discussion. How many of you here are developers who have projects that maybe have interests in privacy? Do you think it would be useful to have different privacy-preserving things? That's great. I'm super happy. Okay, good. So hopefully we can have a really good discussion as well. I think we should introduce ourselves first, just as people. So, Anya? Hi. Hello, everyone. My name is... My name is Alem Petrovska, I'm the head of research at them, and I'm also a PhD student at the University College London, where I research privacy and hosting technologies, and in particular, another communication network. Cool. And my name is David Rician. As you can see from my last name, I got quite an early start with encryption. I'm a founding member of a decentralized derivatives platform called the Vega Protocol. I previously built a sharded, scalable lock chain and consensus system called ChainSpace. I moved to Libra very briefly, and I thought that I was actually more interested in working on internet privacy issues, and that's why I'm working here at NIM. The wider team, this is the kind of production team, including some of our coders and other surrounding people, and we actually have quite a large team of advisors from across Europe, from four or five different universities across Europe, basically. So, our goals. We have one goal. Ending mass surveillance. Why would we want to do this? Quick, quick kind of overview. I kind of think that the present situation on the internet is something like crypto wars 2, so it's like the sequel to the crypto wars. For those of you who missed crypto wars 1, the original episode, the 1990s were quite, they were quite bold attempts by the US government to legislate things like hardware back doors into computers and network systems, and they basically wanted to pre-root all cryptography at the time. That was their kind of big aim. Strong cryptography in the 90s was classed as a munition, and it was subject to export bans so that you couldn't share it outside the United States. Many arguments against privacy were advanced at that time, and if the anti-privacy advocates had one in the 90s, most of the internet systems that we use today would probably never have happened. But as it turns out, the original crypto wars were one during the course of the 90s. I think that the availability of SSL probably did more to advance security and privacy of the internet in the 90s than anything else. It's rarely viewed this way, but SSL and successor protocols like TLS are a practical and very important contribution to help ensure civil rights worldwide. Transport security is the core infrastructure of global civil society, in my view. It also ensured that a lot of new industries could take root, so things like e-commerce, internet banking, private messaging, photo sharing. Many of the convenience of modern life that we take for granted, everything would be very different today if the coders starting in the 90s had been prevented from protecting user data. Now, today, just like in the 90s, we have a kind of new technical set of possibilities in front of us, and the same arguments about privacy are being advanced. And I think that we have to win the kind of crypto wars, too, in order to make both global civil society secure and also take advantage of the new economic opportunities that we have in front of us. Yeah, so that's, in a nutshell, the reason why we're doing this. Okay, so you might rightly ask how we're planning to do this. We have basically two core technologies in our system. The first one, as I said, is a mixed net, which is a better-than-tor network security layer. And Anya is a mixed net expert. She's going to talk about what better-than-tor means. Not to rag on tor because it actually does a really good job, but there are certain attacks against tor, and we think we can just generally do a better job. The second thing, which I'll talk about, is a signature scheme that provides these properties. And I'll go into those in detail in a little bit. But first, I'll hand off to Anya. Okay, so... The first time I'm using the clicker, so if I might accidentally explode the screen, I'll try not to. So before we're going to jump to discussing what mixed net networks are, let's just discuss what privacy actually means. So privacy is the fundamental human right. And we can think about privacy in the context of legal basis, in the context of human need, and we can also think about privacy in the context of computer security. So in context of computer security and any other, the most general way to define privacy is that privacy is the ability for us to decide what type of information we would like to share with other people or disclose about ourselves. And privacy is a very complex topic because when we are building privacy enhancing systems, we have to make sure that we're going to consider each of the components of the system in terms of privacy. So it's a very holistic property, which means that the information leakage in one of the components of the system may very significantly degrade the privacy properties provided by even the most enhanced cryptographic techniques in the other component of the system. So because today we're talking about NIM and NIM is a system for enhancing the privacy properties of the online users, the most basic component of the system which we want to run online is the network layer security. And when we're thinking about the network layer security, one basic thing which we're thinking about is the anonymity. So what is anonymity? Anonymity in general is the property which allows us to remain indistinguishable among other people performing similar actions or operations. And in the online world we're going to talk about anonymous communication at the network layer. So we would like to hide the fact who is communicating with whom or who is exchanging information with whom. And when this anonymity is important, so if you're going to think about network layer security, you have to think about the metadata. So when the internet was first introduced in DARPA it was developed as a small-side project focused on fast packet switching and it was intended to be used for casual communication, not for exchange of confidential information. Therefore there was a very small amount of thought put into securing actually this communication. And how it turned out this little project ended up being a worldwide project and we all use internet nowadays for everything. And every online activity which we perform leaves a digital fingerprint. What it means that every operation which you perform with every operation which you perform online is associated with the metadata. What is this metadata? The best way to define metadata is to say that it is everything about your communication except the content. So this is information for example about who is communicating with whom, how often, at what times of the day, what is the dynamic of the group, what is the sequence of communication, from which location you're communicating with people and so on and so on. And when the PRIS program was revealed the NSA was saying that hey no big deal that we're trying to record your communication because we are not reading your content, we are just looking at the metadata. But it turns out that this metadata carries a lot of sensitive information about the users which very often is as revealing as the content itself. So you don't need actually try to print the messages and look into the content to infer a lot of information about the users which in result allows you to infer what are their relationship, what are their political or sexual preferences, religions and so on and so on. So let's look at a couple of examples of privacy enhancing technologies which are very popular nowadays. I'm pretty sure you saw or heard at least about one of them. And let's think whether they offer us anonymity at the network level or not and how good is this anonymity. So the first example is end-to-end encryption. I'm quite sure that you either use or heard about PGP for emails or end-to-end encrypted instant messaging applications like WhatsApp, Signal, Telegram and so on. So this is a very good example of a privacy enhancing technology which allows you to have confidentiality. So which allows you to hide the content of your communication but it doesn't protect the network layer metadata associated with your communication. So even though you're hiding your actual messages you're not hiding the fact with whom and how often you're communicating. Another example are the privacy enhancing crypto coins. So I think I don't have to convince anyone that Bitcoin is not anonymous but let's look at more privacy friendly coins like for example Zcash. So Zcash is a very nice privacy supporting coin because it offers a good privacy properties on-chain thanks to using the zero-knowledge technology but it does not protect the network layer. So in a result the adversary who has access to the network layer is able to correlate users transacting just looking at their network addresses. And the last example is VPN so the virtual private network. So here we are getting a little bit closer towards securing the network layer of communication because actually VPNs offer some type of network level protection by offering an encrypted channel between the user and the VPN provider which acts as a proxy. But what is the limitation of the VPN? Well VPNs are centralized which means that simply you have to trust the VPN provider that he will be behaving honestly because he is the one who sees your traffic between the user and the public internet. So in result you have to trust that the VPN is not malicious or it does not keep any logs about your online activities and does not share it with anyone. So the research in anonymous communication networks is definitely not new. Already in the early 80s David Chao pioneered the idea of the first ever anonymous network called the Mix Network. So I will try to give like a very brief crash course on what Mix Networks are. So let's start first what is a Mix? Mix is simply a router, a network router for any type of internet traffic which we would like to use. And a Mix Network is just a set of such Mix Nuts. And don't be particularly amazed that I'm showing the Mix Network as just a single sequence. In general you can have many topologies of this network but just for simplification I have just a single path. But on top of being just a network router the Mixes have some security properties which allow you to remain anonymous at the network layer. So what are those properties? The first property is that a Mix transforms the received packets cryptographically. What does it mean that if Alice wants to send a message to Bob she's going to encode her message into a special cryptographic packet format in such a way that each mix on the path between Alice and Bob will remove one layer of this cryptographic protection. So if some of you know onion routing it's a very similar idea. So we layer and crimp the packets. And what this gives us is the property called Bitwise Unlinkability. This means that if the adversary observes any single Mix and he sees packets coming in and packets coming out he won't be able to correlate them looking at their binary representation. So the bit pattern of the packets in and out does not correspond to each other. Another property of the Mix networks and the Mixes is not related anymore to the bit stream but rather to the timing of the packets. So most of the routers on the network work at the first in first out basis which means the first packet coming in will be probably the first coming out. So imagine your Mix works like that and the adversary observes the Mix and he sees packets coming in and out and even though he cannot correlate them based on their binary representation he will be able to correlate them looking at the time of their arrivals and departures. That's why the Mixes do not forward packets at the first in first out rule. Instead of that they reorder the packets following some secret permutation. What this does is that the timing correspondence between the incoming and outgoing packets is broken up. And there are many different ways to perform this reordering following secret permutation. The original Chown's Mix networks operated in synchronized batches which meant that the Mix is waiting the whole round which can be for example an hour or something like that and gathers some packets processes them and at the end of the round apples throwing a secret permutation and flashes to the next hop. So those two properties the bitwise unlinkability and the timing unlinkability allow you to achieve anonymity of your communication. Because the Mixes are combined in long chains and thanks to that none of the Mixes knows who is the sender and recipient because they only know the previews and the next hop they don't know what is the whole path and who is sending messages to call and at the same time the adversary who is observing even the entire network and can sniff all the packets at all the links won't be able to correlate your communication. So as long as at least one Mix in the path is honest your strong anonymity remains. So early Mix Network designs had a couple of limitations in terms of performance mostly scalability and very high latency overhead because those batching crowns required a lot of time to wait for many packets to arrive. That's why the NIM Mix Network is based on the modern Mix Network design called Lupix which solves the problems of traditional Mix Networks. So a little bit about how NIM Mix Network works and how we solve those issues of limited performance in traditional Mix Networks. So the first important thing is the network topology. So topology means that the Mix nodes are grouped into layers and the traffic is flowing from first layer to the last layer in one direction. And why did we pick the stratified topology? It's because as research has shown the stratified topology has the best trade-off between anonymity and performance and it's a topology which scales horizontally which means that you can very easily scale your network if the number of users using it increases or the volume of traffic increases because you simply have to incrementally add more nodes. So for example TOR is an example of an anonymous network which also scales horizontally. In terms of the bitwise unlinkability and cryptographic packet format which we're using, we're using the Sphinx packet format. If some of you know Lightning Networks but exactly the same cryptographic packet format is used in the Lightning Networks. And the Sphinx packet format offers the unlinkability of the binary pattern and makes sure that all the messages are padded to the same length. But it also ensures resistance to tugging and replay attacks and it allows to encode all the rounded information within the packet with what means that the sender as soon as he sends the message into the network he can go offline. Which for example does not happen in TOR because in TOR you have to be online all the time to be able to communicate when you're sending packets because you have an open circuit. In the NumMix network because we're using Sphinx we can just send the message and go offline. And in terms of this mixing operation, this reordering we use the so-called continuous time mixes and this is a very nice technique for mixing the packets and how it works. We don't have synchronized runs. We do not batch messages. Instead of that each packet is delayed with some random amount of time. The sender when he's preparing the packet to be sent into the mix network he encapsulates those random delays for each mix on the path. This delay is randomized. And the mix when he strips the level of cryptographic protection he's going to see this delay and he knows for how long he should keep the packet before flashing it. And why actually this is a good technique for mixing? Well, we are picking the delays from the exponential distribution and the exponential distribution has a very nice property called memoryless property. What it means imagine you are the adversary and you're observing a mix node and you see one packet arriving at some time and then another packet arriving to the mix at another time. And then you see a packet leaving the mix. This memoryless property tells you that you cannot guess which of the incoming packets is the one which you observe going out because the timing at which the packets departure from the mix is not correlated to their arrival times. And what it gives in the big picture it increases the anonymity set. Because in the synchronized mix networks you have the anonymity set of the size of how many messages you've managed to gather during the round. Here, because everything works in a continuous manner and the exponential distribution is long hailed, your anonymity set is much larger because you actually have to consider all the messages which you've ever seen arriving to the mix node as being potentially the one departuring. And the last thing about the NimxMixNet is that it's very intuitive that when we're talking about anonymity the larger the group of people among which your anonymous, the better is your anonymity. So mix networks very often use covered traffic. But the problem with the traditional mix network design was that this covered traffic usually required a lot of bandwidth. That's why in the NimxMixNetwork we're using a tunable covered traffic. A tunable means that when the volume of real traffic increases in the mix network you can tune down the amount of covered traffic which you're using and vice versa if the amount of real traffic is dropping. And the type of covered traffic which we're using is called a loop covered traffic. A loop means that the sender and the recipient of this packet is the same person. And both the clients and the mix nodes are sending loop covered traffic following the Poisson distribution. This ensures that the packets, the real ones and the loop packets are very nicely mixed together so the adversary cannot distinguish looking at some sample of traffic whether he sees real messages or loop messages or have have and so on. But the loop messages they also have another very big advantage. They allow to detect and prevent active attacks in which either malicious mixes or malicious adversary can block or drop some of the packets in the network. These are properties which were not in the traditional mix network designs so it's a very big advantage. Ok, just to wrap up about the NIMS mix network is like the key takeaways you should remember is that we have a mix network which has a very good anonymity versus performance trade of. The network scales very well we can adjust the latency which we need in our system depending on the amount and volume of traffic which we have we can detect and resist active attacks. So that's about mixed networks. Alright, thanks Anja. So that's half of our system and by the way we're going to try to do we're going to succeed in doing a demo because we don't have any dependencies on internet because I shot a little movie last night from my hotel room so we'll actually be able to see some of the stuff happening. So we built a small chat application just as a kind of tester and you'll be able to see messages going into the mixnet and going between two terminals as a kind of simple example but you could use mixnet for many more things than chat. You could use it to pretty much anonymize any of your blockchain transactions any of your cryptocurrency transactions or anything else for that matter. The second part of our system is a system of privacy preserving credentials so we're working at different layers here. A mixnet defends you at the network layer whereas the credentials that we have can defend you at the layer of your transactions or your blockchain. So the mixnet protects your IP traffic as it's traveling across the unprotected wilds of the internet and the privacy preserving credentials allow you to encode cryptographic claims and use them. So we're using a signature scheme called coconut. So what is coconut? Well, coconut is a signature scheme and as you may know all signature schemes have at least these three algorithms that you need to be able to generate your keys you need to verify a signature that you receive and somebody has to be able to sign basically. So given the public key of the person that you want to sign a message for you should be able to sign that thing and if anybody who has the public key that was signed with should be able to verify, right? So everybody's pretty much familiar with these things cool, a lot of noting here, it's very good. Cool. So name signatures are, it is a signature scheme but we have several additional properties. So the first property that we add to the sort of normal three we have blind signatures or blind issuance. Do people know what that means? Some people, not everybody, okay cool. So again cryptographic genius, invented blind signatures which have some additional properties and functions. Let's take a fictional eCash scheme just to kind of use an example to try to walk through what a blind signature is. So I'm going to create a cryptographic claim so a piece of cryptographic material that basically says what I want to end up with is a bearer token saying I have one dollar, okay? That's our aim. Don't take it out of the blockchain world for just a second. So I'm going to create this claim saying Dave has one dollar and it'll be in clear text. Cool. So I blind it locally on my client and that turns it into gobbledygook so it's just a piece of stringy stringiness and I'm going to send it to the bank over the network along with a dollar if I could transmit a dollar through the pipes. The bank is going to then sign it and saying they attest yet Dave definitely has a dollar, we're holding it. Cool. Now he's got this claim that he can run around with and they give me a signature back. So they've signed basically a piece of blind cryptographic material they give it back to me and now I've unblind the credential and I can basically delink that from what I got back from the bank. So I now have a bearer token which attests that I own a dollar and yet the bank never actually they can't really identify me because all the other material literally in that blinded credential they never saw it they just saw some gobbledygook so this process of that so create the clear text blind the clear text locally send it to the signer the signer signs it return it to the creator and the creator unblinds it to use it as a bearer token this is the kind of general process of blind signatures now some of you may have noted that there's a problem with blind issuance so you could have made an unsigned that you have three dollars. Exactly, so the signer has just been presented with this gobbledygook and they've signed it and they've given it back to me so it could have said Dave has one million dollars and they would be unable to tell without some further active verification so if you're the bank you get some gobbledygook the usual solution to this is to use a zero knowledge proof a testing that the message contains one dollar but reveals nothing else so the serial number of the credential the T, anything like that so there's a bit of zero knowledge action inside this so coconut, our signature scheme has this zero knowledge proof ability so that's one of the things that it does so it can do blind issuance cool a second thing that we have is the concept of re-randomizable signatures has anybody ever run across this before it's a pretty weird one I'm going to demonstrate it in a little bit but this type of signature has an additional algorithm to these three which is basically randomized so you basically can take a signature and then from that signature you can call the randomized method on it and you can basically generate a brand new credential which is cryptographically equivalent to the original credential that you originally had in your hand is completely delinked completely anonymizes the cryptographic material that you have a barotoken so it looks like a brand new credential that's sort of unlinkable between the two but it can still be verified through cryptography as if it was the original one so I'll demonstrate that in a bit but that basically can make your barotokens untraceable so you get a barotoken back from some kind of authority you call the re-randomized method on it you get a new barotoken that has the same cryptographic material but the authority can't say I saw that one and I gave it to it does that kind of make sense? okay cool okay so what is this used for so you can create multiple signatures and show them to different people but the people that you show it to cannot link you back to the original signature or to any of the other re-randomized signatures but the underlying messages in this case is all the same so the cryptographic content is all the same across all these credentials basically have multiple anonymized barotokens that can each be validated as if they were the original so we have the property of unlinkability cool we also have a concept of selective disclosure so in a traditional scheme when you sign the message and when somebody verifies the message they have to verify the whole thing so selective disclosure means that instead of needing to verify the whole message you can have people verify only certain attributes in the message keeping other parts of it private so let's consider an example again to make things easier let's assume that we have a passport so my passport has my name, my nationality age, photo and place of issue so these are the attributes in the passport let's say I want to go to the pub and have a drink and I mean I'm so old that I would never need to prove that I'm old enough to get in to produce some kind of ID and you could in an electronic way you might send your whole passport over and identify yourself completely but actually can anybody see what we actually need to get into the pub here age and photo and actually we don't even really want to say how old is Dave because he's really super ancient what we really just want to say is he's over 18 so that's basically what we want to selectively disclose so coconut allows us to do this so you basically sign a tuple of all fields in the passport and when it comes to verify the verifier can verify only some of the attributes despite the fact that the rest of them are still there you can selectively choose to disclose these things and you can selectively choose to disclose different ones to different people basically so basically we have three parties we have the passport authority the subject that's whoever wants to go in the pub and then we have the relying party we call it which is the bouncer at the pub door and you can basically choose to selectively disclose some or all of the attributes in the message so when you put it all together selective disclosure can be applied to normal signature schemes without blinding without re-randomization so you can design message from an authority and disclose them selectively and this provides privacy against the relying party the bouncer and also against the passport authority right oh sorry if you go to the pub again or if the passport authority wants to without the other properties that is blind issuance and re-randomizable signatures they can identify you the second time you go to the pub as being the same person or the passport authority to break your anonymity if they wanted to if we combine all of these things blinding credentials re-randomizable signatures and selective disclosure we can protect the user's privacy against multiple shows that is uses of the credential at the pub so the bouncer will always think it's the first time you've been there which might be important in certain applications and we can also protect you against the passport authority thinking the credentials you're using to what they issued now keep in mind we're not really talking about making a passport authority any kind of authority that you want to have that can assert any useful information about anything in your applications can be contained inside a new credential so all the elements thus far basically existed in the cryptography literature and we were just stringing them together this isn't some mind-blowingly new set of things maybe you haven't heard of it before but all of this stuff basically exists but they only existed in centralized systems so up until now it's been impossible to string these things together in decentralized systems and that's what coconut basically gives you is this one more thing which is threshold issuance so you can actually have a decentralized set of authorities all generate part of a credential so that allows the kind of decentralization and the kind of blockchainization of using these kinds of attributes for the first time so we're not aware of anybody else who's done this so it makes all of these other things like blind issuance reanimizable signatures, selective disclosure usable in a blockchain context so this is known as a threshold signature scheme so that's basically what coconut does and what the mixed net does maybe I'll break for some questions here just to keep things going back and forth and then I'll do a quick architecture diagram of what we have running right now and then I'll show that that can show some of this stuff in action so questions, any I'm reading the text it rings a bell we're repeating it it rings a bell that I ok so the question is what is the tagging and replay attack so a tagging attack is if the adversary is able to sniff a packet going through the network then flip like a single bit for example in order to be able to like trace this packet further in the network so if you don't have a cryptographic packet format which will be resistant to that it will just flip a bit and then be able to trace the packet the replay attack can be used also for tagging it means that you're repeating the same packet once again just for example to see where it will go again so you're able to sniff it and then resend it again you mentioned that you like set out to basically build something that's better than TOR in terms of network security so the main attack against TOR is essentially a government agency running like 30% of all nodes and by having a majority of exit nodes they just see where all the packets end up how do you address that attack so for example the thing in TOR is that all the packets are going like all of your communication packets are going by the same circuit so with the same entry and exit node here in the mixed network every packet is going by an independent path which is selected randomly so this is already causing a little bit of trouble then it's not that the agency just you know like try to control some of the exit nodes and so on another thing is that when we run the mixed nodes there are a couple of techniques which allow you to detect any nodes based on the reputation so try to build the reputation which nodes are the honest ones and which might be malicious ones quick one, is there any validation for all the nodes yes so exactly I don't know if you want to yeah so we basically just to complete our give a quick maybe visual overview and that might help partly answer some of the question we basically have two chunks of our two parts of our system at the top here is the mixed node and then we also have validator nodes of decentralized authorities that communicate among themselves in a kind of BFT round that and we have some dummy service providers over here built as well to talk about you know to answer your question we have a system which we haven't yet built so all of the stuff I've just drawn here actually is running right now and people can start to integrate against it try it out this new thing that I'm about to talk about doesn't yet exist as running code because it's only a few weeks old so it's kind of we just haven't had chance yet to actually put it together but it's essentially a way of saying okay cool the original Lupitz design I need to take a bit of a detour but I'll get back to it was okay cool your client starts sending stuff so we have a packet which is like here think of it as like some encrypted Russian dolls that all kind of open up right so the center doll the littlest one is the message you're actually trying to send then there's these layers of encryption and that basically defines the path that goes in here comes out here goes this way ends up at this storage node over here and then the offline client maybe that was here maybe somebody comes out of the metro something like that grabs that and actually gets the content delivered right now the original design of Lupitz which is something that Onya worked on was very individualistic so you can do loop traffic it's called and you can be spitting even if you're not sending any real messages through the system you might be spitting loop traffic through so your packet might go boom boom boom boom and actually loop back around to you and say cool wow my message made it through so you send maybe one every ten times you send a loop packet around and you can you can basically see cool these guys delivered my message right the problem we have to solve is okay if this is me I'm a good person I would never say anything wrong how can we if we just rely on the users to do this measurements that I could also be an attacker right so we have to come up with a way of verifying the behavior of each of these nodes in a way that's publicly verifiable in a way that's kind of akin to like a BFT consensus system right because I could say hey my packet never made it past here and if we rely on my individual judgment I could be the attacker trying to damage the reputation of this node right so we basically come up with a way of using a verifiable random dysfunction to pre-generate a bunch of packets and assign them to clients the clients will send them through the VRF will be revealed at the end of a timed round and we can then check does the Merkle trees of each of these nodes which they've been keeping for record keeping purposes basically they have to show the Merkle trees and the commitments inside the Merkle trees that each node has they send that back to the staking authorities and the staking authorities can then verify did they do the right thing at a kind of system level not at an individual level so this is something we've just come up with it's probably the first time that anybody's come up with an incentivization system that works with a mixnet like this so we're quite proud of it we haven't built it yet though I would just suggest to wrap up this incentivize system is that we're checking the quality of service offered by the mixes and if we see that some mixes are behaving dishonest or in a malicious way we're just cutting from their stakes so and if you're acting honestly you can get rewards for you oh that's a good one yeah cool yeah as far as I understand it Tor just has a very simple it just send the messages out directly there's a mixnetwork what to use a push on distribution for the sending out the messages and also the different classes of applications will have different profiles how do you want to create those profiles for the different applications what processes and tools will you use to create those yeah so just make sure I understand your question you're asking like if we discuss different use cases where people send different volumes of traffic for example like a chart application and a bitcoin wallet will have different yeah so just to give you a little bit of the background in the Lubix design and hence in the mixnet we enforce kind of the clients to send following a push on distribution what does it mean imagine you have a phone and you press the button send your message is not immediately injected into the mixnetwork instead of that it's buffered in like a special queue which is controlled by the push on process and from time to time at random times this push on process wakes up and checks this buffer if there is a real message you pick this message and send it if there is no real message he sends a loop cover message what this gives you is that your sending pattern is unobservable so from the perspective of the adversary who's observing your client it just looks like you're always sending something but whether you're sending real traffic or just cover traffic we don't know that so coming back to Amir's question if we have different use cases like instant messaging or email so one is fast and the other is slow sending then we can adjust this push on process to be sending faster on slower but we actually all the time obfuscate the sending pattern of the client so the adversary cannot tell whether you're actually communicating with someone or you're just being completely on hold so yeah we have a very preliminary let's call it demo nobody tries to judge us on our graphic designer or anything like that I'll just build the client we have a really cool graphical introduction to the client as well basically I'm about to run it here just so you can see what it says I've edited an Alice user so it's like Lupix client in it Alice Alice now gets some private and public keys generated and stored on her system cool we started to run in the kind of Lupix client binary which you'll be able to you can integrate against if you're actually interested in like trying to make your applications work with a mix that we have a bunch of running mix that notes we have this topology of six notes running on the internet right now with two storage notes at the end so even if you're your kind of end user clients are offline you can do that as soon as we told Alice as soon as Alice said hey I'm going to run this client the client automatically starts sending packets so it starts encrypting packets through the system and sending them back to herself it starts generating cover traffic as soon as the client has started up this client doesn't do anything else than that so you might be a bit disappointed if you just like fire it up and then you'd be like wow that doesn't really do anything but it is actually doing something if you like if you wire shark yourself you'll be able to see the cover traffic going however we're basically within the next week we're going to be able to build a set of socket interfaces so you can just have this binary sitting inside your application you can connect it to it by either a web socket or a TCP socket and just push bytes into it and those will be those bytes that you push into it will basically go through the mix that and you'll be able to send messages so as a kind of example of that we're building a chat client and we've got it built I'll just show it right here so I'm just going to I'm just backing out I'm saying okay cool we're going to go to the chat client demo and I'm going to spark it up so we're going to use this Alice thing this Alice user cool so now again it says what Alice's public key is and she has to figure out who she wants to communicate with we've also made a Bob user and I'm just going to start him in another terminal there start up Bob good cool he selects Alice's public key which has to be sent out of band so he has to know that cool now we have this two message thing now just as that kind of goes through I'll just explain what's going on we have two clients both of them start sending cover traffic and we have a dashboard that you can actually see on the internet right now it's at dashboard.nimtech.net and you can we're always sending cover traffic through that anyway and you can basically see that the cover traffic going through the nodes because it tells you you know this node here let's say in the last one second it sent 20 packets and it received 18 packets or 12 packets whatever whatever it happens to be so you can basically get a view overall of the whole network and what's happening within it yeah so you can see the speeds this is actually going through from my hotel room in Japan to our mixnet in Europe somewhere through the six nodes and then back out back to Japan so it's you can see the speeds actually not that bad as far as when something is typed in here or you can see it appear on the other side quite rapidly so it's definitely sub second latency it's like sort of 300-400 milliseconds I'd say of latency that gets added at that thing so we can also see the mix nodes and the validators here as well and if I just back it up a little bit I think you'll be able to see here inside there you can see it says received and sent in that one second period that's what the mix nodes are actually receiving in and you can see you can kind of tell that the reordering is happening inside the nodes because otherwise the numbers would be exactly the same I've sent and received in that one second period and they're not across all of those things so that's the reordering of the packets if I have a server can I contribute like resource right now already or yeah I guess so there's the repos that we have are completely open the chat client might not be but that's more an oversight the main nodes both the NIM validator nodes that run the credential system and the mix nodes that run the mixing system it's all open right now so you can look at it and have a look it's not super beautiful yeah go ahead two questions the first one is how the directory service is provided like how do I know what nodes there are so right now we're running a directory server at directory.nintec.net it's centralized at the moment but that's a temporary thing because we need to bootstrap the network and then I need to figure out what my next move is going to be as far as just distributing the presence information around we have several good options for doing that I just haven't picked one yet so second question what is the significance of deciding in advance the delays why cannot but why cannot the individual nodes just come up with random delays so there are a couple of reasons why the first one is if you're in the center and you're picking the delays in advance for each hot you know where your packet should arrive at the other end this allows you to for example expect an acknowledgement for your packet so you will know whether your message got to the other end or not whether one of the mixes dropped it or not so that's one of the advantages and yeah it's the main one because also it will allow you to detect malicious mix nodes if your packet you didn't get the acknowledgement for your packet this means that maybe your packet will drop somewhere on the way and you should investigate which of those mix nodes potentially dropped your packet and so on I just see that here received and sent I expected them to be equal so you're not received and you're not sent and they're quite different they're supposed to be different because the packets as they're received are held for random amounts of time so that's why we get the reordering so if they were the same that's when we would be unhappy knowing like why why it's just what if it's just passing the same things in and out in the same order and it's not reordering anything what it's actually doing is we can tell it's working because it's holding the packets for a random interval and therefore we can see that it's actually mixing but why didn't some nodes send more messages than theirs it's like this is my first packet so they also like imagine like in one second you receive 10 packets in the other second you send 5 of them and then you receive another 5 and then you send 15 so like there is all the time just shopping the packets yeah cool sorry go ahead so the client binary is the thing that you'll want to use it's written in go right now so if you're a go user you can just compile the client right into your software if you're not a go user we're going to provide socket connections so let's say we're a javascripter just for instance there'll be a web socket connection basically your javascript application has to fire the binary up that will take care of all the key generation all of the loop cover traffic all of the kind of mix and eddy stuff for you and then you subscribe to events on that web socket and you can push events into the web socket so from your point of view you're making a chat application with a web socket or you're making some other application socket in javascript and it goes into the go binary the go binary goes hey cool does this guy have any like real stuff to send no cool send a cover message good or if you have real stuff to send yes then good we'll send we'll send you real stuff and it will take care of all of that stuff for you and the client also takes care of going to the directory server looking up where all the nodes are downloading by grabbing their public keys getting the whole network topology everything like that and then the client will automatically do your client side writing for you so you never as an application developer need to think about you know what path am I going to choose or anything like that it's all done for you so if I have a service inside me that's for example a service like a sending a file could I retrofit curl to fetch the file by going through a sub proxy locally you would need to packetize it that would be the one thing that you would need to do in that case so if you need to chop up that file into chunks that match the size of the mix net packets and at the other end of your application you would need to provide some way of turning those packets into something that maybe gets reordered if you need ordering in your application so that's the actually like an IP layer without TCP kind of it's like a super anonymous UDP I guess we've just reinvented this one more thing that we've got here which is a quick demo of the credentials I'm just going to jump forward a tiny bit just to see if you can see it running cool we're just loading up some configuration files but basically what we have here is a wonderfully designed QT thing which basically will take some ERC-20 token in just as a kind of demonstration it's not for any real reason what I'm trying to do is demonstrate the kind of flow so basically what's going to happen is the client that's this white thing you see on the screen will ask for hey here's Ethereum we're going to ask for Ethereum to basically pump some Ethereum tokens into NIM into this Tenderman round which is what we're actually using for the validators that will create some NIMs in the Tenderman side of things you'll then get back a credential from the validators so all these guys will respond to you and say cool yeah here's each piece of your credential because you get a threshold credential we can then re-randomize the credential and we'll show that working and then you can spend the credential with a service provider and the service provider can then redeem it over here and say cool pay me and we can have double spending production there as well so that's the basic flow of the coconut credentials so cool we just got 10 NIMs in we're going to create a credential that codes 5 NIMs in this case don't get sucked in by thinking you always have to put currency inside your credentials this is a very general purpose system so the NIM credential is the same thing as like this application is like a smart contract as it's what a smart contract is to the EVM the basic thing underneath all of this is very general purpose cool we've got back a partial credential our client has reassembled it over here and I'm pressing the re-randomize button and you can see the credential changing right there as I'm pressing it so I just re-randomize it 5 times it has now the same 5 NIMs inside the credential that it always had but it is a totally different credential than what we got back from these issuing authorities so they can't rat on me anymore they can't tell who they gave it to even if they colluded it would be unable to do that so we then send the credential from our client to some kind of service provider to pay for something could be for anything that's great the service provider redeemed it that means it's been spent I asked it to spend it again and it said no, you've already spent it the really interesting thing I'm going to re-randomize it another 5 times here so you can see the credential changing again sorry if it's a bit I try to spend it now and despite the fact that it's a brand new credential the blockchain has rejected it as being already spent so the cryptographic material in there has been recognized as a brand new credential so we still have double spending production even with the re-randomization cool that's pretty much it so any other questions how is your work funded? we have some investment from different VCs so talking to the service provider could you still identify sure it doesn't right now but eventually the vision is that it will be better what VR of construction are you I'm not sure I don't know which VR of construction I think I heard I don't remember the person who invented the two people who invented the scheme aren't ready here so I'm not sure what they're planning to use there so I can't say and also we are working on the research papers related to that so probably what the research paper will be out of the description so I just wanted to say that following your question we are working on the research paper about this so in the research paper we will probably discuss which VRF to use and which one is the best so the VRF would also be used to randomize packets sent inside a mixed node the client will still generate the path but the mixed nodes will need to say what they saw afterwards the VRF comes into play everybody opens up the box and goes hey did Timmy mixed node 2 actually send the correct packets and there's going to be a record of what he was supposed to have sent basically and this VRF is used only for those special measurement messages which are checking the quality of service the regular messages it's up to the client what he is using to ping the path how he likes and so on cool, thank you very much for the time but if people want to keep on chatting out in the hall please come say hello and if anybody is interested in trying out some of the code or trying to develop against this then please come talk to me as well. Thank you