Yeah, we're here to listen again. One of the big problems of today is how to communicate without all of those gumshoe people

sniffing up behind you, including picking up your metadata from the commercial side of whatever the system is. And this is another try if I rightly inform. The problem is with most of the stuff, you still, you either have to be linked to some

GSM number, or you have to have a wifey around, you need some IP connection. Obviously people have been thinking about that. And this is Torsten, his full name is Torsten Grothe, excuse me, I'm pronouncing it the

German way, and he's part of the Briar team since two years. He's originally from Germany, he's a pre-software activist and a programmer, and he lives in

Brazil. Envy. Where's your tan, by the way? Okay, so let's have a big hand for Torsten Grothe, who's going to present Briar to you.

Thank you very much all for coming here today, for taking time out of your busy congress schedule. I hope you had a great congress so far. And thanks for coming to hear about Briar, so let's get right into it.

What is Briar? Essentially, Briar is a communication tool, you could say. It is being developed since 2012, so quite some time. And some of you might be thinking now, yet another messenger, like don't we have too

many of those already? And I totally agree, like who of you has at least five messengers on your phone that you use to connect to people? Yeah, it's crazy. I think it's a third of the audience who has that. So I can only recommend everybody don't build yet another secure messenger, unless it's substantially

different from all the others that we have so far. And to motivate a little bit why we need yet another one, let's look at some of the threats that people who use messengers are facing.

Before we got into this, sorry, I forgot this slide. Briar is focused on security and resilience, and I think especially this resilience part is something new, and we're here in the resilience track of the Chaos Communications Congress, so this will be important as well. So now back to the threats we are facing when we use communication over the internet.

The classical one is eavesdropping. They read our messages, but we want confidentiality. And eavesdropping has been largely solved by end-to-end encryption. Essentially means at the source of the communication, the message is encrypted, and at the destination,

it is decrypted and nobody in between, not even any servers on the way can read the content. That's great, and there have been some awesome advances in the last year that made end-to-end encryption usable for everybody, so you don't see any keys any more, you don't need to sign anything, it just works, it gets out of your way, and this is the way it should be.

The only problem with end-to-end encryption is that it still needs more adoption, and I'm especially looking at you, hello, Facebook Messenger and Telegram, where end-to-end encryption is available but not activated by default, and that's something that I hope

will change in the future as well. Next problem, metadata. You're here at the Congress, you probably know all about it, so I will be brief. Metadata is data that is not the content itself, but everything else, like the time of your communication, who you are communicating with, and how much.

And that is almost all that your adversaries need to know about you, because it tells a lot, and you can deduce a lot of information from it. And this problem has been largely ignored, unfortunately. There is just a few projects to try to address that, but it's a very important one, and if

you don't believe me that it's important, maybe you will believe this guy. First of all, David's description of what you can do with metadata is absolutely correct.

We kill people based on metadata, but that's not what we do with this metadata. Thankfully. Wow, I was working up a sweat there for a second.

So, for those who might not have understood it, he said we kill people based on metadata alone, and he was talking about these two kinds of metadata. He was talking about phone records mostly, and domestic ones, and foreign ones, so he's basically promising, oh, we don't kill the Americans based on the metadata, just

everybody else. So, these phone records, especially when it comes to messengers, are a nice selector, and they are all centrally stored, and your entire address book is uploaded to people's servers, and then the servers know all of the metadata that's going on, and it's

a juicy target for an attack, like if you compromise this kind of infrastructure, you have all the metadata of all the people communicating through the servers, but also timing attacks are quite easy. So, using phone numbers is maybe not the best idea. But apart from eavesdropping and metadata, there is also censorship and service blocking.

So, basically, they block our stuff, and we want to have it accessible. This is just one example here from China, where it happens from time to time, and of course, I know we can usually circumvent stuff like there are tools, but this is for

a technical elite. This is not for the big masses that can just easily circumvent these blockings and censorship. And it happens all over the world. I don't know how much you're following this. This happens in Turkey. In Brazil, the courts are very happy to block WhatsApp once in a while, even though

it's used by almost everybody for lots of important things. And that sucks. It shouldn't be possible, right? This is even worse. Even in industrial countries like Germany or the United States, politicians are seriously discussing to turn off the internet completely.

This is really bad. They turn off, they pull the plug and we lose all access. And that can happen, but thankfully, I think politicians understood that we rely economically a lot on the internet, so turning it off is also a bad idea for other reasons.

But in many countries like Cameroon, for example, where they have this bring back our internet campaign, it's still a suppression instrument by the governments, because the reliance on internet is still relatively small, so people don't start a revolution, then the internet goes down. In India, there have been 69 total shutdowns since 2010 in various provinces, mostly in

the north, and there's many other examples, but I won't show you all of them. So this is when the government is pulling the plug and disconnecting us all. But it could also happen that there is a natural catastrophe.

Infrastructure breaks down, maybe there's not even electricity, the uplinks don't work anymore and we are in a big mess and still need to coordinate help, we still need to communicate, we still need to find people. Another likely scenario that could happen where internet won't be available is the

zombie apocalypse. So if your tool doesn't work while there's a zombie eclipse happening, then maybe your tool is not as good after all.

So now let's look a little bit more detailed into Briar and how Briar is attempting to address these issues. It's still a work in progress, you could see it as a research approach of addressing these problems.

And the main difference is that Briar is not using a server to relay all people's communication. This is how all of these messengers you have on your phone work. There is a central server infrastructure, whenever you send a message, it goes through

there and they know who you are and who you talk to. And if you cannot reach the server, you're out of luck, you cannot send anything. So that's why Briar removes the server out of the equation and connects people directly peer to peer.

So the great thing about this is when you don't need to reach the server anymore, then you can use what you already have in your pocket anyway to make connections to people. And in our case, with our smartphones today, this is the Bluetooth radio and the Wi-Fi

antenna you have in your phone. So people can find each other for Bluetooth. People can find each other in local lands, in Wi-Fi networks, and then they can directly make connections. And this is only good for short range, unfortunately, because our phones are designed

like that. But it still is good if you live in a densely populated area where a lot of people and the social network is strong. So there, the short range doesn't matter so much. But Briar has been made in a way that data can be transported through

whatever means, like as long as you have a simplex or a duplex data stream you can send, you're fine. At the moment, we don't have these, but you could easily imagine to write just a plug-in to put it into Briar and then you can enhance your phone with one of these, like you can have a satellite uplink, or if somebody knows

ham radio, you can use this with your phone as well or with other devices and extend the range and then communicate over longer distances. And yes, you can even use carrier pigeons.

It's only partly a joke. So, sneaker networks, just put your data on a flash drive, attach it to a carrier pigeon, put it in the mail, send it to your friends, they put it in and they receive the messages. End-to-end encrypted, of course.

So, like I said, we use end-to-end encryption with this authenticated stream cipher there with 256-bit keys. We support forward secrecy as well, of course, but there's a catch. Since data can be transported also through carrier pigeons or whatever means you come up with, there can be long delays for messages to arrive, so you cannot roll keys forward so frequently.

So, each transport has a key rotation period that it uses to establish forward secrecy. And when we have transports that have a very low latency, we can also use ratcheting, but this is still something we need to implement, unfortunately.

So, but when you use this kind of encryption, you somehow need to exchange a shared secret that you use to encrypt your messages. And Briar does this by forcing you to actually meet with the person you want to talk to. And we do this because this is the only way we know of that you can use to prevent man-in-the-middle attacks.

Like, end-to-end encryption is great, but if you have a man in the middle and you don't know it, like, end-to-end encryption doesn't help you. That's why the other existing messengers like Signal or WhatsApp allow you to verify the safety numbers after adding people. Like, Briar puts this first.

There is one thing, though, because people don't like to meet up or cannot meet up, so we introduce the possibility to allow a trusted peer to introduce two of their contacts to each other and then they make a direct connection. So they run a Diffie-Hellman key exchange through the person, and only when both accepted the invitation

and acknowledged that they deleted the keys to establish forward secrecy, then they start making direct connections to each other and are connected in this peer-to-peer network. So Briar only connects to your direct peers. It does not use a distributed hash table or something like this. This is because we want to be able to run this on our mobile phones

and everybody is concerned about battery usage. And a distributed hash table is basically like a big chatter going on. Everybody is talking all the time with everybody. And this is burning your battery because you're sending data, even when you're not using it. So that's why we connect only to direct peers.

Let me advance to the next slide because then you have something to read. These are the cryptographic algorithms we use. And you see there's one on the left side and an arrow to the right side.

This is what we're migrating to at the moment. So we're migrating from Blake to S as a hash and MAC function to Blake to B. And similarly from these brain pool curves, we are migrating to the Edwards curve down there. But can I have internet as well? Because I was talking only about this Bluetooth and Wi-Fi stuff,

but you're not always in close range and you don't always have your ham radio connected, right? So we here, at least, we have internet most of the time and we want to be able to use it. So yes, you can have internet. And how we do this is we use Tor. So Tor is integrated into Briar.

When you install it on your phone, you don't need another app. You just start the app and Tor is booting up without you knowing about it and it starts a hidden service on your phone. I assume that most of you know what a hidden service is, but for those who don't, let me give just a brief introduction.

So this purple cloud is just an abstract way of viewing the Tor network. And there are Alice and Bob and they both have a hidden service on their phone. So they have a connection into the Tor network and each of them are basically picking three Tor relays.

And then they find a rendezvous point in the middle and they establish the connection through this. So they never make a direct TCP IP connection because this would leak metadata directly to any network observer. So if you look at Alice's traffic, you would see there is a TCP connection going to Bob.

But in this case, you just see there is a TCP connection going into the Tor network and you have a hard time following where it comes out. I have to admit, though, that Tor is not perfect. If you have seen yesterday's talk, they say Tor is good, but it's not alone. There are other solutions, but they are also not perfect and there is no anonymity system at the moment

that can resist a global passive network observer, which probably the five eyes can do. So if they can see all network traffic, they might be able to de-anonymize some of the connections, unfortunately. But we can work on this. Like I said, Briar is agnostic to the way data is transported.

So you can just write a data transport plugin, put it in when the next best thing comes, and just all migrate to that without losing your contacts or any of your data. It's just another way to transport data. You can also use all at the same time if you want. So we don't have too much time to go into detail,

but let me explain how Briar works at a little lower level. So essentially, it's simple. You have groups or channels or a pipe, like we know in the Internet is just a series of pipes. And you have messages. And these can be anything you want. You can put your own data in there.

In our case, we have some binary data format that we use, and we open for any purpose we need, we open a dedicated channel. So if you have private messaging, you just open a group between two people that only these people exchange messages through. But you can expand on that, and you can also create groups

where people, like in this case, they share messages with other people. And then you can also share this group with all your other friends. And this is what we call forums. In the forum, everybody can read and write messages, and everybody can share this forum with other people. In the private message context, you cannot share that.

You cannot share your private conversation with anybody else. It's just between you and your peer. And now let's look at this sharing graph. So imagine you have this forum group, which are essentially the pipes, and then you share it with your friends. Then every edge on this graph is a sharing relationship,

and the nodes are the peers, and the green ones are the ones that are online at the moment. So if these people write messages in the forum, they can have conversations, and they only exist on people's phones. There is no service where they can get uploaded to. So there's also no single truth of what is the current state of the discussion.

Because the people that are offline, they only get messages when they're online, but they only get them when they have a connection to people who have the messages. So if these people have messages, they flow through here, arrive on the other side, and they get them right away. But this unfortunate fellow here in the bottom,

he's out of luck because he won't get the messages that are being sent here unless these people or some people along the sharing graph come online. So similarly, when the connecting point here in the top goes offline, and these people keep chatting, these people won't read the messages. And this opens also tricky new problems,

like what happens when you suddenly get lots of messages? How the traditional messaging service do that? They have a linear history, and suddenly if you get two-day-old messages at the top, you are very confused. So that's why we use a threaded conversation structure where people can reply to each other in branches,

and later you can merge these branches back together to have a continuous and consistent message history, where you can also find stuff again. So this is a very simplified view of the architecture of Briar. You see in the bottom, the blue box is what is called Bramble,

and this is released as a separate library. It gives you the peers, the cryptography, the database to store stuff, and the message synchronization through these various data transports. The gray boxes we have not yet implemented but plan to do so.

So here, LAN, Bluetooth, Tor, maybe later I2P and Wi-Fi Direct. And then on top of this Bramble library, we have the Briar core library, which gives you all the features that are just built on top. We have messaging forums, blogs, groups, and an RSS import into the blocks. This is also for censorship circumvention,

when you have friends on Briar that share RSS feed content with you because you cannot access it wherever you live, maybe, like BBC News in China or something. And then on the top, we have the actual applications that make use of the libraries. So at the moment, we have an Android app and we plan to have a desktop program.

And we structure this this way in libraries, so you can build your own peer-to-peer things with this technology without starting from scratch. So please go and decentralize all the things.

And I'm really serious here. When I started out advocating for decentralization, I was always thinking, Federation is the way to go. We are nerds. Let's all build our own servers. Let's put our servers in our houses and federate with each other.

But now I think the perspective is a little screwed because we are nerds. Yes, we can do this. But we cannot expect other people to do it. And Federation is great. It's an improvement over the status quo. But if we could migrate the existing services that we use on the internet into a truly peer-to-peer infrastructure, and this is even better,

because then we don't need any servers to run. We don't need any servers to maintain and be even more resistant to censorship and we can just rule around it. And I don't know if you have seen it. Just before my talk in the Salt Dijkstra, there was a talk about claim chains, which enable you to also put trust relationships into peer-to-peer networks in a privacy-friendly way.

So these kinds of new technologies would be great to enable all sorts of new peer-to-peer applications, even if you need trust, like in the sharing economy, like if you want to do some sort of peer-to-peer Uber or peer-to-peer Airbnb. Like, let's do it, please. And I hope Briar's technology can help you maybe doing it.

So we have at the moment an Android application that you can get on Google Play or better, Android, right away, and test it out, play with it here on Congress. And if you want, meet me later here next to the stage and then we go somewhere and we can add each other and try how good it works.

And to anticipate already a question that we get a lot, but I have iOS, like where is your iOS application? And we would like to have some iOS applications because one of our target audience are journalists who need to communicate securely with their sources and these people have iPhones all the time. So we looked into it and so far it doesn't look good because iPhone closes all applications quite soon

after you put them in the background and you're not allowed to keep TCP connections open and we need to do this so you can get messages. So if you're an iOS developer and you have some ideas how we can get around this, please get in touch. And the source code is of course free software

available for everybody to use and we're also working on making it build reproducibly, which is very important because you need to be able to verify that the source code actually matches the binary that we ship and everybody needs to be able to verify that so nobody can build any backdoors inside. So we have always a source binary correspondence.

And the latest versions mostly build reproducibly but there's still some kinks we need to work out unfortunately. So I'm at the end of my presentation. Thank you very much for your attention and I hope you have some questions.

That was awesome, eh? I beg your pardon. Questions. Who has a question? There's mics left and right. Internet. Signal Angels. Yup, Signal Angels has a question from the Internet.

Go ahead. The Internet wants to know how it's different from RetroShare and does it have additional features of some advantage in the protocol? Well, I'm not a RetroShare expert so I can't take this with a grain of salt. But as far as I know, RetroShare uses DHT infrastructure

so it is relaying messages between peers all the time which would burn the battery if used on mobile quite a lot. And it basically does everything but it doesn't care as far as I know so much about the metadata being leaked and also as far as I know you cannot use RetroShare with other kinds of data transports easily

like we do. Thank you. One sentence with a question mark at the end of it. Yeah, I would like to see to know what are actually the difference with the Ring project. I heard about the Ring project which is also a kind of decentralized messaging services.

Actually, I followed a couple of conferences from this project and I saw that a lot of features were missing because of the structure of it. Decentralized, you don't have the history you cannot have several devices that are synchronized together for your own account and these kind of things. So what is your point of view on those kind of features? Well, I also don't know the Ring project but it's great to know that there is more of these things happening.

And I don't say use Brian, that's the only truth. Like, let's build whatever works, right? And your point about multiple devices is indeed something also we have not solved because if you are in a peer-to-peer network and you have two devices, you need to consider the case where you go online with one device, you make one action in the application

and then you go online in the other device before it is able to sync this information and you make a conflicting action like leaving a group and posting a message. So it looks like you left but you're still posting something and how to resolve this? We haven't solved it yet. Okay, thank you.

We have four more minutes, question, one sentence, question mark. You mentioned iOS, what are other ways that people can help Briar? Well, there is lots of ways that people can help Briar because there is lots of work to be done. One thing that would be nice would be to have a desktop client and essentially we just need the UI on top of the libraries that we already have so this is something where people can get started easily

but we also have, of course, a bug tracker and a feature tracker where people can just say, hey, I want to implement this and then we help you. Signal Angel, no? Yes, yes, yes. Go ahead. Okay, the internet wants to know what happens if an attacker gets hold of the device. Is there some kind of deniability or something?

Well, deniability is not one of our design goals. However, it's an Android application and most people on Android, they don't have a full disk encryption or anything like that. So what we do to improve the situation is to encrypt all data that Briar stores in its own database

with a password key duration function based on the password so whenever you go online, you need first to enter your password to decrypt the database and then there is also a panic button feature like when you have a panic button app and you're like, I don't know, the police is coming to arrest you and you press the panic button, then you can have Briar deleting the database

or just locking out so that the data address is at least secure. Thank you. Two more questions. One left, one right. The right one starts. Thanks for your talk. How do two peers find each other in the Tor network?

This is where hidden services help us because the Tor hidden service has a unique address which is essentially its public key and there is directory service in the Tor network. When you come online, you get listed there and this is how they find you. So you don't need to use any firewall punching, any natural stuff. You just go into Tor network and you say, I want to connect to this hidden service

and if they're online, they will respond and if not, not. Thank you. Last question from my left here. So you use Bluetooth currently to connect but recently there was discovered some important vulnerabilities regarding Bluetooth which makes it not advisable to use Bluetooth at all in Androids.

So how do you handle that? Yeah, that's unfortunate and Bluetooth not only has lots of security problems but it's also very flaky and difficult to work with. So our response to that was to be more conservative on how long Bluetooth needs to be enabled. So we tried to reduce the time and it's also possible that you don't need to use it at all.

There are still some improvements that we do and also one of our latest contributors, he implemented a prototype of a Wi-Fi direct plug-in where two phones can connect to each other directly with Wi-Fi without being in any sort of access point. And so maybe when we're lucky in the future, we don't need to use Bluetooth at all.

Okay. Let's have a big fight. Whoa, whoa, whoa. There's still seven. No, I have to cut off. I'm sorry, the next talk is going to be Max James. He's going to be packed like hell and we're going to get the people in and out first. So I have to cut off here. I'm awfully sorry.