 I strongly believe that the balance between liberty and oppression in our world is ultimately determined by the balance between offensive and defensive technologies. Imagine a world where defensive technology always prevails in every area of human life. Basically, nobody would be able to harm anybody else. Any kind of coercion would be impossible. Imagine the unprecedented level of liberty and security for all. And so if we want to advance the cause of liberty, we should strive to develop all kinds of defensive technologies. And this is Whisper's all about. So today we're going to talk about achieving darkness with Whisper. So Whisper is a messaging system for distributed applications and at the most secure mode of operation is supposed to be able to achieve darkness at considerable expense in terms of processor power, bandwidth, etc. So what is darkness? It's a property of the system when no meta information is being leaked and goes hand-in-hand with plausible deniability. For example, if the message is found on your computer, nobody can reasonably assume that this message was addressed to you because this is part of the protocol that the node stores and forwards all the messages. So Whisper was designed to be an integral part of Ethereum ecosystem and it offers off-chain communication between the apps. So it has nothing to do with blockchain. It's off-chain. And the reason for that is because off-chain communication is much cheaper and if you don't need consensus, you just need to send a message, you use Whisper. And so Whisper uses underlying Ethereum communication protocol to take care of message delivery. And Whisper is a gossip protocol. It means that every message is delivered to every node. So now we're going to talk about the technical details. Alright, thanks. Yeah, so this represents a network and you have nodes on the network, obviously. And each node has a key. And if a node at the center wants to send a message to a recipient, what it does is that it encrypts the message with nodes, the recipient's key. And so it will then forward the message to its neighboring nodes and those nodes will try to decrypt the message. They will fail because they don't have the right key and they will forward it to their nodes as well, to their neighbors as well. And so on until it reaches the recipient that manages to decrypt the message. You will notice that actually that doesn't stop here. Even though the message has reached its recipient, the recipient will still forward to its neighboring node and that's to not be identified as the recipient, otherwise that would leak metadata. So these are a lot of messages. How do you prevent people from spamming the network? We use proof of work. I assume I don't have to tell you what it is. But yeah, that's how you throttle the traffic on the network. So there are some advantages to this approach. First, it's decentralized obviously because you do not have to send it to one central authority like WhatsApp or Google Talk. You can also agree on a protocol with your recipient on how to generate keys so you do not have to store the keys on disk. And you have two other advantages, darkness and steganography but Vlad will be talking about that later. We were not kidding when we said that would come at a significant cost. The problem of this approach is that it has a high latency a high bandwidth obviously everybody's sending messages to everybody else. There's a high processor load because you need to try to decrypt messages even if they're not intended for you. And on top of that, you need to keep a copy of the messages in memory because you might be sent messages that you already sent and you do not want to overload the system with sending extra messages. So you need to keep messages in memory a bit longer and that's costly as well. So the way the message works, we have time to leave an expiry which is what I described, how long you should keep the message in memory. You have the nonce which is related to the proof of work and you have the encrypted payload which is the message itself. And we also provide a heuristic to help the nodes determine if it's worth decrypting the message or not to try to save a bit of a processor load. So this heuristic is called the topic. It's four bytes of arbitrary data. It's very short, it's on purpose. And the goal for that is so that you cannot be identified with your topic. So other participants on the network will probably set the same very probably set the same topic. So you will be able to deny that the message was intended for you. In version six, we also want to let the nodes decide what kind of topics they want to receive and that will reduce the darkness but that will also reduce the workload so it's an help to improve adoption so that people do not spend as much resources when adopting whisper. So let's talk about achieving darkness. We should assume that our adversary is very powerful and it owns a lot of nodes on the network, maybe more than half of the entire network. And also it is capable and willing to target individual nodes so it can brute force generate the whisper identities of its nodes in such a way that they fit into the network topology completely surrounding the target node and with the purpose of performing the traffic analysis. So for recipient it's quite easy to achieve darkness because recipient gets all the messages, tries to decrypt them in case of success, reads the message and nobody from outside can detect it. The only thing the recipient should take care of is treat all the messages equally. So even those messages he can read should be forwarded. And if you use defaulting limitation of get then it's already taken care of. But for the sender of course in some cases the adversary can see that the message was originated in this node. So how to achieve darkness? Well you can try to maintain certain level of noise. For example you send messages every so often and if you have something to say you encrypt a meaningful message if not then you encrypt some random data and it will be indistinguishable. And also I would recommend to use different topics and keys and whatnot for incoming and for outgoing messages because imagine if you have two nodes on the network they communicate with each other so you cannot really detect who communicates with whom unless those two nodes send messages with the same topic or those messages share other traits. Message size, frequency, proof of work and so on. And so it's better to have the messages outgoing and incoming don't share common traits. So message size is another important metric which can potentially leak information and that's why we have introduced the padding field. So imagine that you have you maintain a level of noise so you send messages every so often and every message is approximately 1 kilobyte and then all of a sudden you need to send this short message like in this case goodbye big brother and then it's very different. So what you can do, you can randomly generate some data and put into the padding field and then you encrypt the entire message and those fields are indistinguishable and so you can adjust the message size and our default implementation already includes that so every message has size which is factor of 256 bytes but our API allows easy access to this field so you can actually set any size you want. Also our default implementation allows symmetric and asymmetric encryption for messages. In case of symmetric encryption if you engage in this communication with somebody else it means that you have already exchanged the secret key through some kind of secure channel and I would recommend to use exactly the same channel whatever it is to exchange also the topics and all the other related information and yeah so it's easy but for asymmetric encryption what usually happens is you advertise your public key in some open channel and you probably are not willing to publish the topic because in this case message sent with this topic adversary can guess the message was addressed to you so but if you try to decrypt all the incoming messages it might be too expensive in terms of processor power so what you can do you can require higher proof of work for messages without the topic and also you can advertise partial topics so for example you say if the first byte of the topic contains certain value for example 0 then you will try to decrypt this message I would also recommend to use the long term keys only to establish the session so you generate session keys for outgoing and incoming messages you generate the topics preferably randomly and you send the first message to establish the session and this message will be encrypted with the long term key and then you proceed to communicate normally with ephemeral keys and after the session is over the keys are deleted and nobody will be able to decrypt those messages again if you don't store them so another important thing in our implementation is steganography support so we have this padding field and normally it's generated randomly but our apli allows easy access to this field so what you can do you can substitute the padding with some secret message for example you have some secret message in this case lorimipsum and then you encrypt the message with some completely different key you put the encrypted message in the padding field and then you compose some innocent looking message like in this case I have nothing to hide and then you encrypt everything and you get the encrypted message and so in the future if your communication is compromised or worse if the adversary will force you to reveal your long term key then the adversary will decrypt the message and they will see this innocent looking part and random looking payload and they cannot reasonably assume that this message this payload sorry this padding field contains some secret message because all the whisper messages contain this padding field so we are officially implementation agnostic so what you can do with our implementation of whisper you can set up your own private network and it has a number of advantages first of all in private network you may have only trusted participants so you don't expect any spam and therefore you don't need any proof of work requirements so you can abandon that and also the number of nodes is relatively low so you don't have bandwidth constraints and so you will not have latency and you can engage in instant messaging you can engage in voice calls, video calls, whatever and the only thing the adversary can say about the participant is that they are part of this network and in case of some organizations it's already known also some people ask me if it's possible to use their custom encryption instead of whisper encryption because they don't trust our whisper encryption and I'm always happy to hear such questions because it shows that people are serious about security and the answer is that you cannot substitute whisper encryption by the custom encryption but you can encrypt on top of our default implementation and our API allows easy access to do it and in cryptographic community it's usually discouraged to use custom encryption but in this case if you do it on top of our whisper encryption with unrelated keys you can do no harm and I actually want to encourage people to continue research and development in encryption because first of all we should not be complacent and on the other hand it's looking very promising actually this is the first time in history that certain technology namely cryptography offers such a huge advantage to the defenders of those who try to attack and of course all kinds of self-appointed visa bodies are going to be very unhappy about it because they see the writing on the wall that technology makes them obsolete and they will no longer be able to control the free speech and all the king's horses are not going to help them and if you hear them saying that encrypted communication is very dangerous and especially if they advertise their services to protect you from those dangers just remember that we are talking about very peaceful technology here which can be used solely and exclusively for defensive purposes so here are our contact details please join our Gitter channel or write to us on Gitter and we will be very happy to assist especially if your project seems to contribute to the cause of liberty so we of course cannot help everyone but we will try to assist Whisper integration with any substantial project and now we have a little bit of time so maybe we will take a couple of questions so one is the proof of work and Whisper version 6 is going to be dynamic so you can dynamically send proof of work and if traffic is too high you can increase it on the fly but also we will have bloom filter exchange protocol for the topics and so you will be able to set up those bloom filters in such a way that you can probabilistically assess how many messages you get for example you want to reduce your traffic by 90% and there will be formula how you can set the bloom filter Can you repeat the question please? How do you access the system just using a normal email so if I just want to get some protection of my normal email can I use this for doing it? Good answer No sorry It's a bit embarrassing but could you please repeat slowly? So I'm an Australian so put all my words together I want to say that so No worries mate So if I'd like to use this to protect my standard email and I want to access this level of protection with my emails how do I do that? So I guess it's a question for the Dapp developers so those Dapps who use Whisper for their communication they should take care of that Maybe there will be some Dapps which provide email-like service based on Whisper and maybe it's going to be status, maybe somebody else So we hope, yeah, we hope it's going to happen Okay so I'm just, you know, I'm developing a Dapp that's going to have a front-end in JavaScript connecting with Ethereum So are you kind of envisaging that this gets implemented in a front-end Java library to communicate with other peers around the network? Oh jeez, that's pretty... So you want to use the, I didn't quite hear So you want to use the JavaScript library? So I'm asking, you know, where are you seeing this protocol being implemented on what kind of level of the stack at the front-end or how can you use this in the back-end library? So you have an RPC interface so you have a JavaScript, it's part of a Web3 so you can always communicate with that but under the cover, under the hood, it's RPC call so you can just send HTTP request so if you want to implement it in back-end you can do it this way And yeah, if you need a library for a specific language you can always contact us, I mean we're willing to help Yeah, great speech. So I guess my question is can this decentralize the system be used for something outside of Ethereum? Like if I wanted to build out a messaging app that takes advantage of all the benefits of the system can I somehow utilize that? Like Android, iOS, messaging app, you know, that would be pretty cool So as I mentioned before, officially we are implementation agnostic so you can even deploy your private Whisper network and use it for whatever purposes you see fit So you may not be able to answer this but is there any risks associated with ultimate liberty and also for, is it entirely a defensive technology because of the fact that people could use negative conspiracy and non-repudiation and some of these other tools to communicate it basically conspire Yeah, so they can even use it to spread heresy, apostasy and all kind of dangerous things So why I mentioned those quasi-religious things is because government usually uses those So my answer is that people did conspire and people did commit a lot of crime and they use all kind of stuff to do it roads and cars and what not and so this is what we are doing this is purely defensive technology you cannot use it to attack somebody you can use it to defend yourself even if you're a criminal or if you're a normal person you can only use it to defend yourself and whatever the people will later say that is aggressive and what not it's obvious that it's purely defensive, right? All right, I suggest you come to us and we'll have a longer debate because we are running out of time and we have one more question How much can we expect the network to scale with our current computational resources I mean of the home users in terms of how many nodes can we run so it's feasible for the network to support all that traffic? Yeah, we're actually working on that one It's pretty, I mean right now given the protocol it's still really high like the load is really high so the scaling is still a problem and this is why we're going to introduce V6 so we don't have numbers yet but if you're interested we can keep in touch and I'll send you the results when we start developing it Thank you