 Okay, who of you have done some crypto? Who of you have done crypto parties or explained something for your parents or set up the computer? And who was quite hard-pressed to explain all this to the others? Because, well, it's not as easy as it seems to be just to be crypto. And we always have to do the balance between safety on one side and usability on the other side. And Hido Widmont will now explain us how it is possible to combine both in one go by thinking a little bit around with the protocols. Give a warm applause, please. Well, thank you very much for coming this so close to midnight. Sometimes they say five minutes to midnight is the point where you really have to take action. So maybe it's a good coincidence that this talk is just five minutes to midnight. I guess cryptography should be easy, but so far everyone finds it hard and finds it hard to do correctly. So after the hour, I hope I can give you another vision. So yeah, this talk is not about cryptography. I'm not a cryptographer and I hardly understand any of those cryptographic protocols. But that's not really the issue. I understand how to use them. This talk is about making it easy to use cryptography. Effectively, I'll make it so easy that you don't even know that the cryptography is there. It should work for the user. So what I want to achieve, now I have to scroll here. So yeah, I'm going to do things with cryptography that probably no one has done before. Maybe if some people have done it before, they might find it crazy. The things will be crazy, but I hope it will show you things that can be done if you go the crazy way. At the end, I'd love to hear your reactions. So let's consider what's up. What's up? Is it easy? Yes, there's one billion people who can use it. Easy views of what's up is not really a problem. It's also end-to-end secure, so that's something that's already often in the marketplace. But how secure is it? And the thing with what's up, it's a closed binary. So you don't know what you exactly get. They use the signal protocol from open whisper systems from some people who really think about cryptography. But you never know what they put in the binary, so that's the issue. The other thing about what's up, they maintain the address book, which contains the list of what public keys contain to which users. So that's also in their hands. The third part about what's up, it's that I lost my speaker note, so I have to do it from head now. So that's the challenge. The last thing about it, all the traffic goes via the network. So if they manage to do something sneaky, you probably will not find out. So would you trust your life secrets with some end-to-end system that you cannot verify? I don't use it, and that was the issue for another talk today. But yeah, what's up? Not really so sure, so let's build our own what's up. And this time we built it with secure end-to-end messaging. And the first thing I'll show you is a demo of what we can, of how it will look like. There it comes. I hope it's big enough. I'll start my user agent. The user agent is the program that does all the cryptography for the end user. The user doesn't have to do much work. I should press this full-screen button. I hope it's the right one. Green one, yeah, you're right. There it is. Does it look better to you? Wow, that's not really... This window just is the debug output of it. So I'll go to my browser, open it. Do I open it? Yes, there it is. And here is the website. It looks like the 80s, but yeah, I only promised you three things. Easy, secure, anonymous, beautiful is something else. So yeah, this is a blog site. This is a site where people can open a blog and write their information. So let's do that. Well, let's check out the blogs. Oh dear, it's completely empty. It's completely fresh. Usually you would find a list of blogs and you can read them. But yeah, we're the first one, so let's create a blog. And now... Oh dear. I need to have an account. Well, it's Shah, so let's create the account Shah1. Oh dear, an old account, but let's register. And here on top, the white part. That's my user agent that says that I'm now logged in with user Shah1. And this is the site. So I'll write a blog and press send. And now here is the blog. So let's go back to the list of blogs and there it is. So my username, as you can see here, Shah1, double ampersand, CryptoBlog.domainame. And I use a double ad because it's not an email address. You can't send mail to it. It's just an identity. So there's another user opening their agent, browsing the blogs. And there's a blog. And now we can send a comment. And yeah, I'm even so lazy for this demo, it's late. I'll just accept the standard and say post it. And here's the blog and here's my comment. This is all public information. In my protocol, I have two types of information. You have public information like this. I have private information. So let's do some private message. So I want to send a private message. Oh dear, I need to log in. Well, I'll log in. Shah2, we're improving. And there's the text and I can send a message. And it will be delivered. And that's all what you can do with messages. So go back to the other user. Check out messages and there's the message. Now, I think I've done the same with ease of use as WhatsApp. But the difference is this is fully end-to-end encrypted and not even the website. This blog site can read what the user, Shah2, just wrote the user Shah1. And later I'll show you how. And for that, I'll go back to my presentation. Watch the button for that. It's a Mac, is it? Say again. Okay, I'm stuck here. Host key and F. Yes, you're right. Thank you. So, okay. So, you've seen my blog and WhatsApp. Well, there's some differences between them. In WhatsApp, you have a single identity and that's your telephone number. In this blog, you can have as many identities as you want. There's no telephone number to tie it to. You just created names Shah1 and Shah2. I could have created anything. In WhatsApp, there's no anonymity because it uses your phone number as identifier. And phone numbers, yeah, they're long-lived. You probably have one that you use for all your things. You may have a second telephone if you're in the position that you need one for your job or something. Or if you're a drug dealer, then you may have two or three. But that's it. The other differences with WhatsApp, yeah, need to grow a bit in the user base. So, why does WhatsApp only offer a single user identity? Well, they're in the business of spying on the users. Even though it's end-to-end encrypted, they really want to know who you're talking to and probably, yeah, they want to have the option to get into your data stream if some government thinks they need to know that. But yeah, why go to the service provider? If we can get that risk out, I would be happy. So, I think I can do that. So, here's just the first strange thing that I'm going to offer you. A publicly posted message that is signed with a private key is effectively a key exchange. I wrote in my blog from the user Shah2 to user Shah1. I wrote a private message. Normally, I wouldn't know who the other user is this time in terms of me, but usually I wouldn't know if there's a blog on any other subject. Then, yeah, you see the text of the blog, you see the handle, but you don't know the user. And with this protocol, that's the same. You don't know who the other user is. But once you have to validate that key, you have a secure path between you and a stranger. And once you have that secure path, no one can get in between. You don't know who it is, but you have a secure path. But don't forget, it's still a stranger, so don't tell anything that's dear to your heart or don't tell anything that you're late with taxes or something like that. You never know what the other party may do, but that's with every communication protocol. So, the thing is, I have this message, but I need to validate it. So, let's see how we can validate a certificate or a public key. This is one way. This is the PGP key signature parties. And what they're doing is validating each other's passport. And if they're happy with that, then they sign an email address. They sign the PGP keys of other users, so you create this network. But what happens, these are validated by passports. So, you lose your anonymity because everything you do with your key is effectively tied to your passport. It's not out there, but if you use that PGP Web of Trust, you're effectively using the personal identities of the person, like exactly my identity, who I am, and not just the nickname. So, is it anonymous? Absolutely not. So, let's build our own CA. In this part, I will really get technical. So, the website, in my blog site demo, it runs its own certificate authority. And this certificate authority is only used by the site. No other site is going to use it because every site, a site wouldn't trust a certificate authority from another one. We've seen the examples with the commercial certificate authorities. DigiNotre got hacked and they got sent out false certificates. There's other ones later. So, don't trust a certificate authority from another one. Even if you pay money for it, it might not be worth it. So, what I do, I connect the site to the certificate authority. They are just part of one... There are parts from one group. No, let me try again. The certificate authority is connected to the site. It signs the client certificates for the site, and these client certificates are what lets the user log in into the site. A certificate, in this case, it's just a nickname, the public key, and the stamp from the user. There is no real name in it, there is no need for it. So, for signing up at the site, you'll see that the site doesn't need an email address, it doesn't ask you for it, it doesn't ask for passwords and doesn't want passwords twice. It just accepts the certificates. And you've seen how fast it was, I typed in my name and I got a certificate at that point. But there's one requirement for these certificates. If I have a normal block site, for example, a block site or a new site, say slash dot, for example, you can have your handle, but there's only one of them. With this, I need to have the same. I want to have each user a single handle, or more handles, if they want to, but I want to tie each handle to a certain public key. And that's the public key that belongs to the private key of the user. But the reason why is that people are good with handling these user handles. But for the computer, that's just a string, you can't do anything. The computer needs the public key. But public keys are way too... We'll build it for users. No one can remember the public key. No one can do even RSA calculations in their head. So that won't work. So the validation rules of this certificate authority is very simple. If the nickname hasn't been used before, then sign the certificate for the user. And for this demo, I made sure there was no user SHA1 and SHA2. Otherwise, I would have got an error. And if you get an error, you get it immediately. So, because this sign up, it's just a database lookup to see if the name is used and it's a sign operation. And that can go quite fast. How fast can you get a certificate? Well, you can get it in a tenth of a second. Basically, a single HTTP transaction. Just look up the name and if the name is not used, we'll sign it. Yeah, I already mentioned it. Why the unique names? I wanted to have this to make sure that users... The user names, the account names are unique, and the private keys are stuck to that. So, we have the certificates. Now, how does the login process look? Well, we have the certificate authority above. He's doing nothing anymore, actually, because both participants on this side, Mr. Boop on the left and Ms. Janet on the right, they already have the certificates they can log in. Just what would happen with commercial certificates. So, this made the login process very, very quickly, very easily. But this is actually what we came here for. We want to read the messages, see the... read the blogs, and if we find an interesting blog, we want to send either a comment or a private message. So, we want to send the private message. So, the user requested the certificate with the public key, encrypts the message, sends it to the site, because the site is the only entity that knows the other users and can send messages. There's no email, there's no back channels or whatever. The site has to handle it. So, the site has the option to block the message or give it on. That's the only thing that the site can do, decide not to give it on. But in this case, the message gets on, but Boop has a problem. This might happen. It's getting a bit more complicated, but Boop is still requesting a public key with the certificate from Ms. Janet, but the certificate authority is giving a wrong one. It's giving a duplicate, as I call it. But there's no way for Boop to verify that it's correct. So, what happens? He sends this message and the site cooperates with the certificate authority, changes the message for something else, and you never know what's happening. So, this is really a problem. So, how can Boop verify that he's got the right certificate? Well, for that, now I'm really going crazy. I'll start this global registry of dishonesty. It's a central registry. It should be worldwide unique. Everyone would need to know it. And everyone who comes to a site with this protocol, with this login protocol, they are encouraged to submit their certificate to the registry. It's a bit like Google's protocol certificate transparency for server certificates, but in this case, I'll use it for client certificates. And why? Well, in this case, you might see it at the bottom right. When Boop requests... Boop doesn't request the certificate from the CA anymore. He asked at the registry, which certificates do you have for this user ID? And the user ID is just the username. In this case, for my demo, I used SHA1 and SHA2 domain name. So, that will be the key to look it up. If Ms. Janet is looking up, she gets just one certificate, so that's good. So, she's quite sure now that there's only one certificate in the registry. For Boop, if he's going to look up Janet's certificates, there are two. There's one from Ms. Janet herself, and there's the fake one from the certificate authority. And now the reason why I call it registry of dishonesty, this is proof. This is cryptographic proof that the certificate authority violated the rule that the nickname should be unique because there are two certificates with the same nickname. And what the good user agents should do, a user agent should detect this and say, okay, I'm not going to connect to this site anymore because they violated even the simple rule of not signing two certificates with the same name. And what the registry could do, as soon as it detects both, it could even send out a news message out to the world saying that the certificate authority is bad and it should be removed from the internet. Actually, the internet death penalty. With this really crazy central registry, you can be sure that if there's only one, and if there's one certificate, then you can be sure that there's no manipulations going on and that you have the correct certificate with the correct public key of the other party and you can use the key to send messages. With this validation, you know that the certificates are trustworthy. So here's my statement, a published signed message, an independent verification of the uniqueness of the nickname equals a verified key exchange. And that's really the crazy ID that I'm bringing over tonight. And if this holds, and I'm not sure because this protocol really needs an audit, because there might be things that I have overlooked, but if this is true, we can do some very great things. So what can we do with it? We can do our own WhatsApp. You can use it for shops, but why would a shop, say Amazon, want to use this protocol? Well, maybe because it's easier to sign up. Maybe they want to give it to them about privacy, or they might want to make it look like they give about it. But it also works for other sites. Video streaming sites, for example, Netflix, they really don't know who your identity is as long as they get your money and they know who to stream the videos to. And if you're going into some more fancy stuff, there was this site, Ashley Medicine, and they got leaked, and at least one of the users committed suicide because his identity was leaked. If Ashley Medicine would have used this protocol, that person could have deleted a private key from his computer and had plausible deniability that he wasn't the person. So this protocol might even have saved a life. And the real thing is these use cases, they need to know the user by a certain name, but they don't need to know the user's real name. They don't need to use the real identity. If it's important, it can always be asked later. That's not an issue, and if you need, for example, a postal address to send something to you, you have to ask it, and the user should give it otherwise he doesn't get this package. But that's the end, that's outside of this protocol. But newspapers, I added newspapers to it. Why would a newspaper use this protocol? Well, newspapers are mostly seen as a one-to-many broadcast method. You just subscribe to the paper, you get your thing, you read it, you put the fish from tomorrow in it. But also newspapers need input too. There's feeds, there's letters to the editors, and there's discussion forums, and there are whistleblowers. So what would Edward Snowden do? Suppose the Guardian uses this block site, and Glenn Greenwald publishes his articles there, and every article he writes is signed with his private key. Reading the articles, Edward Snowden would be able to verify that there's only one public key and one nickname combination in that registry of dishonesty. If he's happy with that, he can send a message. What would he send? And that answer, I'll go back to the demo. There we have it. Close it. This was my user one. I'll log out as user. Go there again. This is easy. The user agent also works as a key store and as a bookmark site. It knows what users I have at the site. But this time I'm going to create a new blog under the name Gigi, and that's Glenn Greenwald, who writes something about FBI. And post it. There's some other user. Is it the same user? There's two blogs. That's correct. So there's two blogs, and a certain user reads the blogs, says, interesting articles. I have some documents that I want to give to this journalist, but I don't want anyone to know. So what would Edward Snowden do? He sends an invitation to connect. Oh, dear. He needs to create an account. Oh, well. That would be citizen four. Oh. Something went wrong. Maybe I already used that nickname. Okay, let's create an anonymous one. Oh, damn. There goes my demo. Let's see if I can show what... send an invitation to connect. All right. I'm too bad it goes wrong. But this shows roughly what you can expect if I can increase the letters a bit. Yeah. The computer creates a listening point. Actually, it would be toward hidden servers. And if you follow with the thing, your user agent would send that hidden server address in a secret message to the other side. Then you wait until the other side connects. If the other side connects, you authenticate each other with the keys you have here, which you already verified with the registry of dishonesty. So they are unique. And what happens? Do users who have never seen each other before can connect via Tor and can send information? And that's what you can do with a protocol that allows you to verify keys of strangers. And I'm going to give it another try. Maybe it works better. Yes, it does. I'll have this anonymous account, something. So I'll send the invitation. And the invitation will be delivered. So I'll go back to my other account. There should be a message waiting. Yes, this is the message. This is yours, Glenn Greenbold, by the way, that I'm having here. So this is actually what I'm getting. And behind it is a Tor hidden server address. So if I press the thing, this agent is going to connect via Tor to the other agent. And I get a dialing error. These things happen. The reason is Tor is a bit slow with setting up the network. So actually I'm a bit too fast. So try again. Yes. And now I'll have this. Can't see which one. Now I'll have this information. And here I can something about NSA that went over Tor. So two users, two people who have never seen each other, are able to send messages over Tor. Try to do that with Facebook. Try to do that with WhatsApp. Try to do that with Google Chat. And the nice thing is not even my website knows that this is happening. This communication path is happening directly over the Tor network. So my blog site that introduced those people, it's out of the picture. It can disappear from the earth. These two users can forever connect over this Tor network. Although Glenn Greenbold can initiate the connection to the other site. Snowden can't do it yet. That's for that to happen. Snowden should just do the same and send the message over this connection and they have a direct connection. They can keep communicating forever over Tor and no one would be wiser. So all it takes to set up a Tor hidden server between two users is one single message where you can verify the keys. So one message is all that it takes. I think I'll go back to D. What is this? Where's my mouse? Why is it? So in this 20 minutes, I hoped to have shown you that signing up for websites can be much easier. Logging in can be just as simple as a click on a button. We have end-to-end private messages and you can have as many identities as you want. In this example, each of the user agents already had two identities. One for my SHA-1 and SHA-2 and the other was the Greenbold and Snowden versions. So as each website has its own certificate authority, they're not coupled to each other. And because of that, if I have a website here and there's another website over there and I connect with the same agents to the other website, I'll create a new private key, create a new identity and the two can't be linked by the sites. And with that, it's easy to have many different identities at many different sites. And by doing that, I prevent the situation where sites are using my email address and to get to know me and get to link these accounts behind my back. So what else can I give you? I can give Tor channels to everyone. If that's happening, everyone is going to use Tor channels for everyone, that probably makes me a Torrorist. But yeah, so be it. And the good thing about being a Torrorist is if all the connections are going over Tor, then the whistleblowers can hide in their normal traffic and they are very hard to find. And I think in this society, that's something that we really need. And yeah, I said that before. I might be mistaken, there might be something wrong. Don't know yet what. I really love to see people attacking it, finding flaws, finding issues. Because yeah, it really can use a few audits to see if what I'm bringing up is really going to work or if it only stays a dream. If you want to know more, there's a few sites where you can find the information and the source code. And with that, I hope you have enjoyed this presentation. Yeah, thank you. Pleasure. If there are questions, please line up at the microphones. Yes, and please wait. Wow. There are two microphones, then you can also adjust the height. So, Vlad, let's start here. All right, so I have one question. How do you handle reissuance? Because it's a pretty typical scenario that somebody will lose their private key or for example it gets compromised, so they will have to replace their private key and therefore the certificate. How is it handled in this model? I don't handle it yet. That's one of the things, by making it so strict, you get all these nice properties. And these properties may fail if you're going to do revocations or if you're going to have to... A revocation would probably be easy because that's a message that you sent into the registry of dishonesty saying this one is revoked. But I don't have yet a protocol for creating a new one. If you create a protocol and you adhere to the protocol and you see the old one has revoked then it would be still safe. But I didn't design that yet. Because the issue I can see is that anytime you create a second key it will also create a second certificate and therefore be automatically considered invalid by the network because there are two certificates. Exactly, that's the original rule that I gave it but that's the very simple version. If you want to revoke a key and you still have the private key to revoke it then you can send a revoke message and you can create a new one and that would be the second rule you add to the registry of dishonesty but if everyone agrees on those rules then it would work. I had the same question and so this is also for Bob and Janet this application. Sorry, repeat it please. I had the same question as the previous questionnaire but this application is not only for Assange but also for Bob and Janet from your example. People were not really technical Bob and Janet. The thing is, I've designed it in mind that normal people can use it and all the talks about certificates and cryptography, that's for you but for Bob and Janet it's just the user interface you saw in green it's just create an account and typing things. Have you thought about usability about what if they're in different time zones or do they have to send a private message like I will try to connect to you via this store channel around that time because otherwise I would send an invitation and this window would put up and I would go make some coffee, go to the grocery store go back to my job and there might be one message afterwards and then the next day I get one message back perhaps. Yeah, I think your question is do both users need to be online at the same time? Is that the question? No, if you thought about usability because if I sent you this request and I live in another time zone and you see the request the next day and you accept the request and the connection opens and I leave my computer on all the time because I care about this but then we send each other a message twice a day and we have to send a private message first to... we don't have to send private messages first but we would have a real slow communication in different time zones. Yeah, the user interface really could use a beef up for a production version of this you really want to have this window that comes up and says there's this connection from someone where you can type things in but yeah, you don't know where the other user is, what time zone if they're awake or not, you just get a message and you have to connect. Any improvements on that protocol is just between you and the other party so if this succeeds and this comes up, then probably many people will start creating protocols just for this situation what to do if you create a hidden service. I just showed the chat version I also have a voice communication version but on a single computer with only one audio card that's very hard to demonstrate but yeah, my most simple version of that audio communication channel it really opens the microphone and the speakers and connects them to each other so it would be really a security risk because you don't see that happening for a real protocol real production version you want to have this protocol and it makes a phone bell ring and then you can say yes, I want to open it and yes, I want to answer and then you have it. Great, I can see my parents understanding that. Your parents could understand that, yeah. Thank you. I've been a victim of a melin man in the middle attack and it was through a secure channel I thought so really I think your system is not going to work but put the man in the middle attack in the wrong place usually it is installed on your own PC with meaning that every connection to the outside, also to the registry is being taken over and so you have a registry that if a melin man in the middle attack can fake the registry and send you wrong information then it's not going to work. True. I don't know if you have a solution to this. True. I have two answers for that. I hope I can remember both. The first one is this problem counts not just for this protocol but for every current protocol because our operating systems really are not designed to keep secrets from malware. If a program runs on your computer, is it Windows, Mac or Unix, it has access to everything including your keys and you can manipulate every program so that's one problem. Our operating systems aren't good for that and based on that lots of other nice things that we could have in the past didn't come to fruition. For example electronic cache from David Shum, DigiCache also had the same problem. You want to store private keys on your computer and if some malware comes in and steals those private keys then you're lost. Now what was the other thing? The men in the middle detection on your computer? Could you repeat the question then I think I'll get back to the answer. If you are a victim of a men in the middle attack he can just break all the connections, also the connections to the centralized registry and I think that was the key word the registry. The registry is the weakest point because if two people have really registered the same name with a different set of certificates but the men of the middle attack just gives a different answer, leaves the one record out, then you still think okay it's correct but it's really not correct it is the wrong person Do you understand what I mean? I see where you're getting at. So then you think you are safe but the men in the middle attack could be on your computer but could be anywhere in the network gives you wrong information and then it's broken. Yes, that might happen I'm not really sure how to address that but maybe that's one of the dragons that's in there. Next question. Hi, so I have a question about this registry of this honesty. What happens if the malicious website does not actually report the certificate? So you only reported it. So there is only one there. What would happen if the certificate authority created a second certificate for a user but it didn't post it into the registry of this honesty. That's your question? Exactly. Well in that case, as both parties will look up the key in the registry the malicious certificate doesn't get asked from the certificate authority. The certificate authority can create as many as they want but as soon as he publishes it the registry the alarm will go off so he can't do anything with it. I see. And to help you answer if the certificate authority would be first to publish a fake certificate for me in that registry and I wouldn't publish mine then I would be able to detect it after the first communication with another partner because the other partner would get a certificate and there was nothing. So if the other one would publish it then I might detect it. So after a full run trip of messages where both parties would submit their certificate to the registry you have you have the certainty that you know if there's a man in the middle or not. Thank you. Next question please. So who runs the registry and why do we trust them? Good question. This registry should not be run by the certificate authority or by the site because they would be able to manipulate it. At best it would be either run by some consumer organization or maybe even better a peer-to-peer distributed network over the world run by volunteers maybe run by some ISPs or other parties but independent from the sites. I was wondering about the question about the man in the middle attack whether there wasn't some confusion between a man in the middle attack and a compromised client system. If your client system is compromised, yes, you cannot trust an answer from the site but I believe you mentioned to me once you had a way of identifying the actual site with a great amount of security. I think Dane was involved, right? True. But I'm not sure if that would answer his question but to answer your question I don't think it will answer this gentleman's question but in this protocol I haven't shown you because of this time and this is probably already deep enough. One way for the user agent is to verify if the site is the correct site. The way it does it, the certificate authority and the site they publish the root certificate in DNSSEC and by publishing that service certificate the user agent is able to see if you connect it to the right site because the site's server is also signed with the same certificate authority. So if you connect to a site with a certain certificate authority and the user agent knows it's this certificate authority and have these two keys for that which of those two keys do you want for this certificate authority? And if there comes a phishing attack for example a bank would use this protocol and you get this mail from this scary mail that says something's wrong with your bank and you should log in. If you follow the link you get to a site and the bank should never sign a certificate for any other systems than its own systems. That's not good good measure. So the only certificates, the only thing that the phishers can do is create their own certificate. But that's a different certificate than from the bank. So to your user agent that's a completely new site. So if you want to log in your certificate of your user agent will say oh this is a new site do you want to create an account or just like I got those messages do you want to create an account? And if that's happening then you should probably say hey already have an account at the bank why isn't it there? Then you go back to your list of sites you see the bank is there, you click on it you log in and you're connected to the right side and the phishers don't stand any chance. Does that answer your question? Thank you. You are creating questions of our questions. One question if I understood you correctly you have a local proxy that handles all the private key stuff with the authorities. So how exactly do you intend to support multiple devices? So a user has a computer, a laptop, a smart phone and all this stuff and the private keys have to be exchanged between these devices. How do you suggest to solve that? Well good question. The reason I built it in a proxy server was because it was just the easiest. Eventually you want to build it into a browser but if you build it into a browser you really need to get deep into the browser where it opens the TLS connections and I didn't want to figure that out for browsers because they keep changing so much. Eventually are you familiar with Mozilla's mechanism of transporting your profiles from one computer to the other? Okay well that same mechanism you can use for this instead of passwords and bookmarks you just send the private keys over. You should use a good protocol for that and if this would take off then people will bring, come up with these protocols to do that securely. But yeah if you lose everything then you lose your data so it's a good thing to have your keys in multiple places where you can trust them one in your phone computer, one on a backup disk and so if you lose some then you can go back to your backup disk and get back the keys that are still there. So for that it's not in this protocol but it's something you can do besides and it will really advise anyone to do that. Yes, thank you. Pleasure. I think we saw so many questions this shows that there was really interesting this talk and also that a lot of people were following it and trying to audit your system so. Well, thank you very much.