*36C3 preroll music*
Herald: Please put your hands together and give a warm round of applause to Will Scott.
*Applause*
Will Scott: Thank you.
*Applause*
Will: All right. Welcome. So. The basic structure of this talk is sort of twofold.
The first thing is to provide an overview of the different mechanisms that exist in
this space of secure communication and try to tease apart a bunch of the individual
choices and tradeoffs that have to be made and the implications of them. Because a
lot of times we talk about security or privacy as very broad terms that cover a
bunch of individual things. And breaking that down gives us a better way to
understand what it is we're giving up or whether or why these decisions actually
get made for the systems that we end up using. And the way that it's going to sort
of the arc that I'll cover is first trying to provide a sort of taxonomy or
classification of a bunch of the different systems that we see around us. And from
there identify the threats that we often are trying to protect against and the
mechanisms that we have to mitigate those threats and then go into some of these
mechanisms and look at what's happening right now on different systems. And by the
end, we'll sort of be closer to the research frontier of what is still
happening, where are places where we have new ideas, but there's still quite a high
tradeoff to usability or for other reasons where these haven't gained mass adoption.
So I'll introduce our actors: Alice and Bob. The basic structure for pretty much
all of this is one to one messaging. So this is primarily systems that are
enabling us to have a conversation that looks a lot like what we would have in
person. That's sort of the thing that we're modelling is I want to have a
somewhat synchronous real time communication over a span of weeks,
months, years, resume it, and in the same way that in real life I know someone and I
recognize them when I come and talk to them again I expect the system to give me
similar sorts of properties.
So the way we're going to then think about systems is
initially, we have systems that look very much the same as how we would have a real
life communication, where I can - on a local network - use AirDrop or use a bunch
of things that just work directly between my device and a friend's device
to communicate.
On a computer, this might look like using Netcat or a command line
tool to just push data directly to the other person. And this actually results in
a form of communication that looks very similar. Right, it's ephemeral, it goes
away afterwards unless the other person saves it. But there is already a set of
adversaries or threats that we can think about how do we secure this sort of
communication?
One of those would be the network. So, can someone else see this
communication and how do we hide from that? And we have mechanisms against that,
namely encryption. Right, I can disguise my communication and encrypt it
so that someone who is not my intended recipient cannot see what's happening.
And then the other one would be the other...these end devices themselves.
Right, so there's a couple of things that we need to think about when we think about
what is it that we're trying to protect against on an end device. One is there
might be other bad software that either, later gets installed and tries
to steal or learn about what was said.
Either, either at the same time or afterwards.
And so we have mechanisms there. One of them would be message
expiry. So we can make the messages go away, make sure we delete them from disk
at some point. And the other would be making sure that we've sort of isolated
our chats so that it doesn't overlap and other applications can't see what's
happening there.
So, we have these direct communication patterns but that's a small
minority of most of what we think of when we chat. Instead, most of the systems that
we're using online use a centralized server. There's some logically centralized
thing in the cloud and I send my messages there and it then forwards them to my
intended recipient. And so whether it's Facebook or WhatsApp or Signal or sorry,
Slack or IRC or Signal or Wire or Threema or whatever, you know, cloud chat app
we're using today, this same model applies. So we can identify additional
threats here and then we can think about why we do this. So one threat is the
network. And I'll tear that apart a little bit. You've got the local network that we
had before. So someone who's on the network near the person who's sending
messages or receiving messages, so someone else in the coffee shop, your local
organization, your school, your work, you've got the Internet as a whole that
messages are passing over. So the ISPs or the countries that you're in may want to
look at or prevent you from sending messages. You've also got an adversary in
the network, sort of local or near the server that can see most of the messages
going in and out of the server because these services have to exist somewhere be
that in a data center that they physically have computers in or in AWS or Google or
one of these other clouds. And now you've got a set of actors that you need to think
about that are near the server that can see most of the traffic going in and out
of that server.
We also have to think about the server itself as a potential
adversary. There's a few different threats that we need to think about. The server
could get threatened... could get hacked or otherwise compromised. So parts of
the communication or bugs in the software can potentially be a problem.
You've got a
legal entity typically that is running this server. And so the jurisdiction
that it's in can send requests to get data from users or to compel it to provide
information. So there's this whole threat of what is the server required to turn
over. And then you've got sort of how is the server actually or this company making
money and sustaining itself. Is it going to get acquired by someone that you don't
trust, even if you trust it now? So there's this future view of how do we
ensure that the messages I have now don't get misused in the future?
And we have a
set of techniques that mitigate these problems as well. So one of them would
be we can use traffic obfuscation or circumvention techniques to make our
traffic look less obvious to the network. And that prevents a large amount of these.
And then, I'm calling this server hardening but it's really a sort of a broad set of
techniques around how do we trust the server less? And how do we make those
potential compromises of the server, either code based or it having to reveal
information less damaging?
It's worth saying that there are a bunch of reasons
why we have primarily used centralized messaging.
You've got availability. It's
very easy to go to a single place and it also makes a bunch of problems like
handling multiple devices and mobile push in particular, because both Google and
Apple expect or allocate sort of a single authorized provider who can send
notifications to the app user's mobile devices. And so that sort of requires you
to have a centralized place that knows when to send those messages if you want to
provide real time alerts to your application users.
The cons is that it is
both cost, there's some entity now that is responsible for all of this cost
and has to have a business model and also that there is a single entity that people
can come to and that now faces the legal and regulatory issues.
So this is not the
only type of system we have, right? The next most common is probably federated.
E-mail is a great example of this. An email is nice that now as a user I can
choose an email provider that I trust out of many, or if I don't trust any of the
ones that I see, I can even spin up my own with a small group so we can decentralize
cost. We can make this more approachable. And so while I can gain more confidence in
my individual provider, I don't have as much trust in, you know, is the recipient,
is Bob in this case, I don't know how secure his connection is to his provider.
Because we've separated and decentralized that.
There's also a bunch of problems,
both in figuring out identity and discovery securely and mobile push. But we
have a number of successful examples of this. So beyond email, the Fediverse and
Mastodon, Riot chat and even SMS are examples of federated systems where
there's a bunch of providers and it's not a single central place.
As you continue
this sort of metaphor of splitting apart and decentralizing and reducing the trust
in a single party, you end up with a set of decentralized messaging systems as
well. And so it's worth mentioning that as we sort of get onto this fringe. There's
sort of two types: One is using Gossip protocols. So things like Secure
Scuttlebutt. And in those you connect to either the people around you or people
that you know. And when you get messages, you gossip, you send them on to all of
the people around you. And so messages spread through the network. That is still
an area where we are learning the tradeoff of how much metadata gets leaked and
things, but is nice in its level of decentralization. The others basically
tried to make all of the users have some relatively low trusted participation in
the serving infrastructure. And so you can think of this as evolving out of things
like distributed hash tables that that are used in BitTorrent. You see something very
similar in in things like ricochet or tox.chat, which will use either tor like
relays for sending messages or have an explicit DHT for routing where all of the
members provide some amount of lookup to help with discovery
and finding other participants.
OK, so let's now turn to some of these mechanisms that we've
uncovered and we can start with encryption. So when you're sending
messages to a server by default, there's no encryption. This is things like IRC.
Email used to be primarily unencrypted and you can think of that like a postcard. So
you've got a letter or a postcard in this case that you're sending. It has where
that message is coming from, where it's going to and the contents. In contrast,
when you use transport encryption -- and so this is now a standard for most of the
centralized things. What that means is you're taking that postcard and you're
putting it in an envelope that the network can't open. And that's what TLS and other
forms of transport encryption are going to give you, is the network link just sees
the source and destination. It sees there's a message coming between Alice and
Facebook or whatever cloud provider, but can't look into that and see that that's
really a message for Bob or what's being said. It just sees individuals
communicating with that cloud provider. And so, you know, SMTPS, there are secure
versions of IRC and e-mail and most other protocols are using transport security at
this point. The thing that we have now is called end-to-end encryption or E2E, and so
now the difference here is the message that Alice is sending is addressed to Bob.
And it's encrypted so that the provider Facebook can't open that either and can't
look at the contents. OK? So the network just sees a message going between Alice
and Facebook still, but Facebook can't open that and actually see the contents of
the message. And so end-to-end encryption has gained pretty widespread adoption. We
have this in Signal, for the most part in iMessage, we have tools like PGP and GPG
that are implementing forms of this. For messaging there's a few that are worth
sort of covering in the space: the Signal protocol, which was initially called
axolotl, is adopted in WhatsApp, in Facebook private messaging and sort of
is... I guess it has generalized into something called the noise framework and
is gaining a lot of adoption. OMEMO looks a lot like that specifically for XMPP, and
so it is a specific implementation. The other one is called Off-The-Record or OTR
and Off-The-Record sort of developed a little bit ... or independently from this,
thinks a lot about deniability. I'm not going to go too deep into the specific
nits of what these protocols are doing, but I guess the intuition is the hard
parts here is not encrypting a message, but rather the hard parts is how do you
send that first message and establish a session, especially if the other person is
offline. So I want to start a communication. I type in the first message
I'm sending to someone. I need to somehow get a key and then send a message that
only that person can read and also establish this sort of shared secret. And
doing all of that in one message or with the other device not online ends up being
tricky. Additionally, figuring out the mapping between a user and their devices,
especially as that changes and making sure you've appropriately revoked devices,
added new devices without keys falling over or getting too many warnings to the
error *ehm* too many warnings to the user ends up being a lot of the trick in these
systems. There's two problems that sort of come into play when we start using an end.
One is we need to think about connection establishment. So, so this is the problem
of saying who is Bob? So, so I find a contact and I know them in some way by an
email address, by a phone number. Signal uses phone numbers. You know, a lot of
systems maybe use an email address. There's things like Threema that use a
unique identifier that they generate for you. But somehow I have to go from that
identifier to some actual key or some knowledge of of a cryptographic secret
that identifies the other person. And I have figure out who I trust to do that
mapping of of gaining this thing that I'm now using for encryption. And then also
there's this "Well, how do we match?" So a lot of systems do this by uploading your
address book or trying to match with existing contacts to solve the user-
interface problem of discovery, which is: If they can already know the identifiers
and have this mapping, then when someone new comes in they can suggest and have
"prefound" these keys and you just sort of trust the server to hold this address book
and to do this mapping between what they're using as their identifier and and
the keys themselves that you're getting out. Signal is nice here, it says it's not
uploading your contacts, which is true. They're uploading hashes of your phone
number rather than the actual phone numbers. But but it's a similar thing.
They've got a directory of known phone numbers. And then as people search, you'll
search for a hash of the phone number and get back, you know, the key that you hope
signal has correctly given you. So there's sort of a couple of ways that you reduce
your trust here. Signal has been going down a path using SGX to raise the cost of
attacks, oblivious RAM and a bunch of sort of systems mechanisms to reduce the
costs... or increase the cost of attack against their discovery mechanism. The
other way that you do this is you allow for people to use pseudonyms or anonymous
identifiers. So wire you can just register on an anonymous email address. And now the
cost to you is potentially less if that gets compromised. And it's worth noting
Moxie will be talking tomorrow at 4:00 p.m. about the evolution of the space
around Signal, so there's probably a bunch more depth there that you can expect. So
what if we don't want to trust the server to do matchmaking? One of the early things
that has been around is the web of trust around GPG. And this is the notion that.
I, if I have in real life or otherwise associated an identifier with a key, I can
publicly provide a signed statement saying that I trust that mapping and then people
who don't know someone but have a link socially maybe can find these proofs and
use that to trust this mapping. So I know an identifier and I know that I trust
someone who has said, well, this is the key associate with that identifier and I
can use that network to eventually find an identifier that that I'm willing to trust
or a key that I'm willing to encrypt to. There's some user interface tradeoff here.
This is a manual process in general. And this year we've had a set of denial-of-
service attacks on the web-of-trust infrastructure. And so the the specific
attack is that anyone can upload these attestations or trust, and so if a bunch
of random users or sybils start uploading trusts, when you go to try and download
this, you end up overwhelmed by the amount of information. And so the system does not
scale because it's very hard to filter to people you care about without telling the
system who you care about and revealing your network, which you're trying to
avoid. Keybase takes another approach. They made the observation that when I go
to try and talk to someone, what I actually care about is the person that I
believe owns a specific GitHub or Twitter or other social profile. And so I can
provide an attestation where I say: "Well, this is a key that's associated with the
account that controls this Twitter account or this Reddit account or this, you know,
Facebook account." And so by having that trust of proofs, I can connect an
individual and a cryptographic identity with the person behind who has the
passwords to a set of other systems. Keybase also this year began to provide a
monetary incentive for users and then struggled with the number of sign ups. And
so there's a lot of work in figuring out: "OK, do these identities actually
correspond to real people and how do you prevent a similar denial-of-service--style
attack that the web of trust faced in identifying things here?" On our devices,
we end up in general resorting to a concept called tofu or Trust-On-First-Use,
and what that means is when I first see a key that identifies someone, I'll save
that. And if I ever get another need to communicate with that person again, I've
already got a key and I can keep using that same key and expect that key to stay
the same. And so that that continuation and the ability to pin keys once you've
seen them means that if when you first establish a connection with someone, it's
the real person, then someone who compromises them later can't take over or
change that. Finally, one of the sort of exciting things that came out - this is
circa 2015 and is largely defunct now - was a system by Adam Langley called Pond
that looked at hardening a modern version of email. And one of the things that Pond
did was it had something called a password authenticated key exchange. And so this is
an evolving cryptographic area where you're saying if two people can start with
some weak shared secret - So I can perhaps publicly or in plain text ask the
challenge, the other person: "Where were we at a specific day?" And so now we both
know something that maybe has a few bits of entropy, at least. If we can write the
same textual answer, we can take that, run a key derivation function to end up with a
larger amount of shared entropy and use that as a bootstrapping method to do a key
exchange and end up finding a strong cryptographic identity for the other
person. So Pond has a system that they call Panda for linking to individuals
based on a challenge response and this is also something that you'll find in off-
the-record systems around Jabber. The other thing that we need to be careful
about in end-to-end--encrypted systems is deniability. When I'm chatting one on one
with someone, that conversation is eventually fairly deniable. Either a
person can have their recollection of what happened and there's no proof that the
other person said something unless you've recorded it or otherwise, you know,
brought some other technology into play. But with an encrypted thing where I've
authenticated the other person, I end up with a transcript - potentially - that,
you know, I can turn over later and say, look, this person said this. And and, you
know, we've seen recently that things like emails that come out are authenticated in
this way. The DKIM system that authenticates email senders showed up in
the WikiLeak's releases of Hillary Clinton's emails and was able to say:
"Look the text in these hasn't been changed." And it was signed by the real
server that we would expect. So the thing that we get from Off-The-Record and the
Signal protocol is something called deniability or reputability. And this
plays into a concept of a forward secrecy, which is: We're going to sort of throw
away stuff afterwards in a way that our chat goes back to being more ephemeral.
And so we can think about this in two ways. There's actually two properties that
interlink in this: We have keys that we're using to form our shared session that
we're expecting to use to have our secret message. And each time I send a message,
I'm going to also provide some new key material and begin changing that secret
key that we're using. So I provide a next key. And when Bob replies, he's going to
now use my next key as part of that and give me his next key. And the other thing
that I can then do is when I send a message, I can provide the secret bit of
my previous key. So I can say: "My last private key that I used to send you that
previous message was this." And now at the end of our conversation, we both know all
of the private keys such that we both could have created that whole conversation
on our own computer. At any given time, it's only the most recent message that is
that only could have been sent by the other person and the rest of the
transcript that you have is something you could have generated yourself. There is a
talk on day three about Off-The-Record v4, the fourth version of that, that will go
deeper into that, that's at 9:00 p.m. in the about:freedom assembly. So I encourage
you to do that if you're interested in this. OK. The next one to talk about is
expiry. This is sort of a follow on to this concept of forward secrecy. But
there's sort of two attacks here to consider. One is something that we should
maybe, I guess, give credit to Snapchat for popularizing, which is this concept of
"the message goes away after some amount of time". And really, this is protecting
against not fully trusting the other person from like sharing it later or
sharing in a way you didn't attend *ehm* intent. And this is also like a snapshot
adversary. So a bunch of apps will alert the other participant if you take a
screenshot. This is why some apps will blank the screen when they go to the task
switcher. So if you're swapping between apps, you'll see that some of your
applications will just show a blank screen or will not show contents. And that's
because the mobile operating systems APIs don't tell them when you're in that mode
when you take a screenshot and so they want to just be able to notify you if the
other person does. It's worth noting that this is all just raising the cost of these
attacks and providing sort of a social incentive not to, right. I can still use
another camera to take a picture of my phone and get evidence of something that
has been said. But it's discouraging it and setting social norms. The other reason
for expiry is: After the fact, a compromise of a device, so whether that's
- you know, someone gets hold of the device and tries to do forensic analysis
to pull off previous messages or the chat database or whether someone tries to
install an application that then scans through your phone... So that's Fengcai is
a application that's been installed as a surveillance app in China. And this also
boils down to a user interface and user experience question, which is how longer
you're going to save logs, how much history are you going to save and what
norms are you going to have? And there's there's a tradeoff here. It's useful
sometimes to scroll back. And especially for companies that believe that they have
value added services around being able to do data analytics on your chat history.
They're wary of getting rid of that. The next thing that we have is isolation and
OS sand boxing. Right. So this is a lot of this is up one layer, which is what is the
operating system doing to secure your application, your chat system from the
other things, the malware or the compromises of the the broader device that
it's running on. We have a bunch of projects around us at Congress that are
innovating on this. There are chat systems that also attempt to do this sort of on
their own. One sort of extreme example is called tinfoil chat, which makes use of
three devices and a physical diode which is designed to have one device that is
sending messages and another device that is receiving messages. And the thought is:
if you receive a message that somehow compromises the device, the malware or the
malicious file can never get any communication back out and so becomes much
less valuable to have compromised. And they implement this with like a physical
hardware diode. The other side of this is recovery and backups. Which is you've got
a user experience tradeoff between a lot of people losing their devices and wanting
to get back their contact list or their chat history and the fact that now you're
keeping this extra copy and have this additional place for things to get
compromised. Apple has done a lot of work here that we don't look out so much. They
gave a blackout talk a few years ago where they discuss how they use custom hardware
security modules in their data centers, much like the T2 chip. In the end, devices
that will hold the backup keys that get used for their iclub backups and do
similar amounts of rate limiting. And they consider a set of - a pretty wide set of
adversaries - more than we might expect. So including things like what happens when
the government comes and asks us to write new software to compromise this? And so
they set up their HSMs such that they cannot provide software updates to them,
which is, you know, a sort of a step of how do you do this cloud security side
that we don't think about as much. So there's a set of slides that you can find
from from this. And these slides will be online, too, as a pointer to to look at
their solution, which considers a large number of adversaries that you might not
have thought about. So traffic obfuscation is primarily a network side adversary. The
technique that is getting used as sort of what people are using if they feel they
need to do this, is something called domain fronting and domain fronting, had
its heyday maybe in 2014 ish and has become somewhat less effective, but it's
still effective enough for most of the chat things. The basic idea behind domain
fronting is that there's a separation of layers behind that envelope and the
message inside of it that we get in HTTP in the Web. So when I create a secure
connection to a CDN to a content provider like Amazon or Google or Microsoft, I can
make that connection and do perform the security layer and provide a fairly
generic service that I'm connecting to. I just want to establish a secure connection
to CloudFlare. And then once I've done that, the message that I can send inside
can be a chat message to a specific customer of that CDN or that cloud
provider. And so this is an effective way to prevent the network from knowing what
specific service you're accessing. It got used for a bunch of circumvention things.
It then got used for a bunch of malware things and this caused a bunch of the
cloud providers to stop allowing you to do this. But it's still getting used. This is
still what sort of happening when you turn on certain censorship circumvention in
signal, it's what telegram is using for the most part. And it's the same basic
technique is getting another revival with DNS over HTTPS and encrypted SNI
extensions to TLS which allow for a standardized approach to establish a
connection to a service without providing any specific identifiers to the network
for which service you want to connect to. It's worth sort of mentioning that
probably the most active chat service for this sort of obfuscation or circumvention
is telegram, which has a bunch of users in countries that are not fans of having lots
of users of telegram. And so they have both systems where they can bounce between
IPs very quickly and change where their servers appear to be. And they've also
used techniques like sending messages over DNS tunnels to mitigate some of these
censorship things From the provider's perspectives this is really accessing
their user population. They're not really thinking about your local network or
caring about that as much as as much as they are like, oh, there's millions of
users that should probably still have access to us. So we can maybe hide the
characteristics of traffic in terms of what specific service we're connecting.
There's some other things about traffic, though, that also are revealing to the
network. And this is sort of this additional metadata that we need to think
about. So one of these is padding or the size of messages can be revealing. So one
sort of immediate thing is the size of a chat or a text message is going to be very
different from the size of an image or voice or movies. And you see this on
airplanes or in other bandwidth limited settings: they might allow text messages
to go through, but images won't. There's been research that shows, for instance, on
voice, even if I encrypt my voice, we've actually gotten really good at compressing
audio of human speech. So much so that different phonemes, different sounds that
we make take up different sizes. And so I can say something, compress it, encrypt it
and then recover what was said based on the relative sizes of different sounds. So
there was there was a paper in 2011 that Oakland S&P that demonstrated this
potential for attacks. And so what this is telling us perhaps is that there's a
tradeoff between how efficiently I want to send things and how much metadata or
revealing information for distinguishing them I'm giving up. So I can use a less
efficient compression that's constant bit rate or that otherwise is not revealing
this information, but it has higher overhead and won't work as well in
constrained network environments. The other place this shows up is just when
people are active. So if I can look at when someone is tweeting or when messages
are sent, I can probably figure out pretty quickly what timezone they're in. Right.
And so this leads to a whole set of these metadata based attacks. And in particular,
there's confirmation attacks and intersection attacks. And so intersection
attacks is looking at the relative activity of multiple people and trying to
figure out: OK, when Alice sent a message, who else was online or active at the same
time? And over time, can I narrow down or filter to specific people that were likely
who Alice was talking to? Pond also is a service to look at or a system to look at
in this regard. Their approach was that a client would hopefully be always be online
and would at a regular pattern check in with the server with the same amount of
data, regardless of whether there was a real message to send or not. So that from
the network's perspective, every user looked the same. The downside being that
you've now got this message being sent by every client every minute or so and that
creates a huge amount of overhead of, you know, just padded data that doesn't have
any meaning. So finally, I'll take a look at server hardening and the things that
we're doing to reduce trust in the server. There's a few examples of why we would
want to do this. So one is that you've had messaging servers, plenty of times, that
have not been as secure as they claim. One example being that there was a period
where the Skype subsidiary in China was using a blacklist of keywords on the
server to either prevent or intercept some subset of their users messages without
telling anyone that they were doing that. And then also just sort of this uncertain
future of, OK, I trust the data now, but what can we do so that I don't worry about
what the corporate future of this service entails for my data. One of the sort of
elephants in the room is: the software development is probably pretty
centralized. So even if I don't trust the server, there's some pretty small number
of developers who are writing the code. And how do I trust that the updates that
they are making to this, either the server or to my client that they pushed my client
isn't reducing my security. Open source is a great start to mitigating that, but it's
certainly not solving all of this. So one thing, one way we can think about how we
reduce trust in the server is by looking at what the server knows after end to end
encryption. It knows things about the size. It knows where the message is coming
from. It knows where the message is going to. Size: we've talked about some of these
padding things that we can use to mitigate. So how do we reduce the amount
of information about sources and destinations in this network graph that
the server knows? So this is a concept called linkability, which is being able to
link the source and destination of a message. We start to see some mitigations
or approaches to reducing linkability entering mainstream systems. So Signal has
a system called "Sealed Sender" that you can enable, where the source of the
message goes within the encrypted envelope. So that Signal doesn't see that.
The downside being that Signal is still seeing your IP address but the thought is
that they will throw those out relatively quickly and so they will have less logs
about this source to destination. Theoretically, though, there is a bunch of
work in this. The first thing I'll point to is a set of systems that we classify as
mixnets. A mixnet works by having a set of providers rather than a single entity
that's running the servers. A bunch of users will send messages to the first
provider, which will shuffle all of them and send them to the next provider, which
will shuffle them again and send them to a final provider that will shuffle them and
then be able to send them to destinations. And this de-links. Where none of the
individual providers know both the source and destination of these messages. So this
looks maybe a bit like Tors onion routing, but differs in in sort of a couple of
technicalities. One is typically, you will wait for some number of messages rather
than just going through with bandwidth and low latency. And so by doing that, you can
get a theoretical guarantee that this batch had at least n messages that got
shuffled and therefore you can prevent there being some time where only one user
was using the system. And so you got a stronger theoretic guarantee. There's an
active project making a messaging system using mixnets called Katzenpost. They gave
a talk at Camp this summer and I'd encourage you to look at their website or
go back to that talk to learn more about mixnets. The project that I was, I guess,
tangentially helping with is in a space called private information retrieval,
which is another technique for doing this delinking. Private information retrieval
frames the question a little bit differently. And what it asks is: if I
have a server that has a database of messages and I want a client to be able to
retrieve one of those messages without the server knowing which message the client
got or asked for. So this sounds maybe hard. I can give you a straw man to
convince yourself that this is doable and the straw man is: I can ask the server for
its entire database and then take the message that I want and the server hasn't
learned anything about which message I cared about. But I spent a lot of network
bandwidth probably doing that. So there's a couple of constructions for this. I'm
going to focus on the information theoretic private information retrieval.
And so we're going to use a similar setup to what we had in our threat model for a
mixed net, which is we've got a set of providers now that have the same database.
And I'm going to assume that they're not all talking to each other or colluding. So
I just need at least one of them, to be honest. And one of the things that we'll
use here is something called the exclusive or operation. To refresh your memory here
exclusive or is a binary bitwise operation. And the nice property that we
get is if I xor something with itself, it cancels out. So if I have some piece of
data and I xor it against itself, it just goes away. So if I have my systems that
have the database, I can ask each one to give me a superposition of some random
subset of its database so I can ask the first server, give me items for 11, 14 and
20 xor together. I'm assuming all of the items are the same size so that you can do
these xors. And then if I structure that, it can appear to each server independently
or as in the request that it sees that I just ask for some random subset. But I can
do that so that when I xor the things I get back, everything just cancels out
except the item that I care about. Unless you saw all of the requests that I made,
you wouldn't be able to tell which item I cared about. So by doing this, I've
reduced the network bandwidth. I'm only getting one item of size back from every
server. Now, you might you might have a concern that I'm asking the server to do a
whole lot of work here. It has to look through its entire database and compute
this superposition thing. And that seems potentially like a lot of work, right. The
thing that I think is exciting about this space is it turns out this sort of
operation of going out to a large database and like searching for all of the things
and then coming back with a small amount of data looks a lot like the hardware that
we're building for A.I. and for a bunch of these sorts of search like things. And so
this runs really quite well on a GPU where I can have all of those thousands of cores
compute little small parts of the XOR and then pull back this relatively small
amount of information. And so with GPUs, you can actually have databases of
gigabytes, tens of gigabytes of data and compute these XORs across all of it in
order of a millisecond or less. So a couple of things in this space. "Talek" is
the system that I helped with that demonstrates this working. The converse
problem is called private information storage. And that one is how do I write an
item into a database without the database knowing which item I wrote, the
mathematical construction there is not quite as simple to explain. But there's a
pretty cool new work in the last month or two out of Dan Boneh and Henry Corrigan-
Gibbs at Stanford called Express and Saba as first author that is showing how to
fairly practically perform that operation. I'll finish just with a couple minutes on
multiparty chat or group chat, so small groups. You've sort of got a choice here
in terms of how assisted chat systems are implementing group chat. One is you can
not tell the server about the group. And as someone who is part of the group, I
just send the same message to everyone in the group. And maybe I can tag it for them
so that they know it's part of the group or you do something more efficient where
you tell the server about group membership and I send the message once to the server
and it sends it to everyone in the group. Even if you don't tell the server about
it, though, you've got a bunch of things to worry about leaked correlation,
which is: if at a single time someone sends the same sized message to five other
people and then later someone else sends the same sized message to five other
people, and those basically overlap, someone in the network basically knows who
the group membership is. So it's actually quite difficult to conceal group
membership. The other thing that breaks down is our concept of deniability once
again, which is now if multiple people have this log. Even if both of them
individually could have written it, the fact that they have the same cryptographic
keys from this other third party probably means that third party made that message.
So there continues to be work here. Signal is working on providing again and SGX and
centralized construction for grid management to be able to scale better,
given I think the pretty realistic fact that the server in these cases is probably
going to be able to figure out group membership in some case, you might as well
make it scale. On the other side, one of the cool systems that's being prototyped
is called "cwtch" out of open privacy. And this is an extension to ricochet that
allows for offline messages and small group chats. It works for order of 5 to 20
people, and it works by having a server that obliviously forwards on messages to
everyone connected to it. So when I send a message to a group, the server sends the
message to everyone it knows about, not just the people in the group, and
therefore the server doesn't actually know the subgroups that exist. It just knows
who's connected to it. And that's a neat way. It doesn't necessarily scale to large
groups, but it allows for some concealing of group membership. They've got an
Android prototype as well that's sort of a nice extension to make this usable.
Wonderful. I guess the final thought here is: there's a lot of systems, I'm sure I
haven't mentioned all of them. But this community is really closely tied to the
innovations that are happening in the space of private chat. And this is the
infrastructure that supports communities and is some of the most meaningful stuff
you can possibly work on. And I encourage you to find new ones and look at a bunch
of them and think about the tradeoffs and encourage friends to play with new
systems, because that's how they gain adoption and how people figure out what
mechanisms do and don't work. So with that, I will take questions.
*Applause*
Herald: Wasn't necessary to encourage you to come with an applause. There are
microphones that are numbered in the room, so if you start lining up behind the
microphones, then we can take your questions. We already have a question from
the Internet. Question: Popularity and independency are
a contradiction. How can I be sure that an increasingly popular messenger like Signal
stays independent? Answer: I guess I would question whether
independence is a goal in and of itself. It's true that the value is increasing.
And so one of the things I think about is, is using systems that have open protocols
or that are federated or otherwise not centralized. And again, this is reducing
that need to have confidence in the future business model of single legal entity.
But I don't know if independence is of the company is the thing that you're
trying to trade off with popularity. Herald: Well, and we have questions at the
microphones. We'll start a microphone, number one.
Question: Thanks for the talk. First of all, we talked to you talked a lot about
content and encryption. What about the initial problem? History shows that if I'm
an individual already observed in a sensitive area, that might no need to
encrypt or decrypt the message on sending. It's already identified. I'm sending at a
specific location at a specific time. Is there any chance to hide that or do
something against it? Answer: So make things hidden again after
the fact? That seems very hard. I mean, so. So there's a couple thoughts there,
maybe. There's sort of this real world intersection attack, which is if
there's a real world observable action of who actually shows up at the protest,
that's a pretty good way to figure out who is chatting about the protests beforehand,
potentially. And so, I mean, I think what we've seen in real world organizing is
things like either really decentralizing that, where it happens across a lot of
platforms, and happens very spontaneously close to the event. So there's not enough
time to respond in advance or using or hiding your presence or otherwise trying
to stagger your actual actions so that they are harder to correlate to a specific
group. But it's not something the chat systems are talking about. I don't think.
Herald: We have time for more questions. So please line up in the microphones and
if you're leaving, then leave quietly. We have a question from microphone number 4.
Question: So if network actress
translation is the original sin to the end to end principle, and due to that, we now
have to run servers, someone has to pay for it. Do you know any solution to that
economic problem? Answer: I mean, we had to pay for things
even without network address translation, but we could move more of that cost to end
users. And so we have another opportunity with IP v six to potentially keep more of
the cost with end users or develop protocols that are more decentralized
where that cost stays more fairly distributed. You know, our phones have a
huge amount of computation power and figuring out how we make our protocols so
that work happens there is, I think, an ongoing balance. I think some of the
reasons why network address translation or centralization is so common is because
distribute systems are pretty hard to build and pretty hard to gain confidence
in. So more tools around how we can test and feel like we understand and that the
system actually is, you know, going to work 99.9% of the time for distributed
systems is going to make people less wary of working with them.
So better tools on distribute systems is maybe the best answer.
Herald: We also have another question from the internet, which we'll take now.
Question: What do you think of technical novices, acceptance and dealing with OTR
keys, for example, Matrix Riot? Most people I know just click "I verified this
key" even if they didn't. Anwer: Absolutely. So this, I think
goes back to a lot of these problems are sort of a user experience tradeoff, which
is, you know, we saw initial versions of Signal where you would actually try and
regularly verify some QR code between each and then that sort of has gotten pushed
back to a harder to access part of the user interface because not many people
wanted to deal with that. And an early matrix riot you would get a lot of
warnings about: There's a new device. Do you want to verify this new device? Do you
only want to send to the previous devices that you trusted. And now you're getting
the ability to sort of more automatically just sort of accept these changes and
you're weakening some amount of the encryption security, but you're getting a
better, smoother user interface because most users are just going to sort of click
"yes" because they want to send the message. Right. And so there's this
tradeoff: when you have built the protocols such that you are standing in
the way of the person doing what they want to do. That's not really where you want to
put that friction. So figuring out other ways where you can have this on the side
or supporting the communication rather than hindering it is probably the types of
user interfaces or systems that we should be thinking about that can be successful.
Herald: We have a couple of more questions. We'll start at microphone
number 3. Question: Thank you for your talk. You
talked about deniability by sending the private key with the last message.
And how I you get the private key for the last message in the whole conversation
Anwer: In the OTR, XMPP, Jabber systems there would be an explicit action to end
the conversation that would then make it repudiateable that would that would send
that final message to to close it. What you have in things like Signal is it's
actually happening every message as part of the confirmation of the message.
Question: OK. Thank you. Herald: We still probably have questions
, time for more questions. So please line up if you have any. Don't hold back.
We have a question from microphone number 7.
Question: So, first of all, a brief comment. The riot thing still doesn't even
do tofu. They they haven't figured this out. But I think there's a
much more subtle conversation that needs to happen around deniability, because most
of the time, if you have people with with a power imbalance, the non repudiatable
conversation actually benefits the weaker person. So we actually don't want
deniability in most of our chat applications or whatever, except that's
still more subtle than that, because when you have people with equal power, maybe
you do. It's kind of weird. Anwer: Absolutely. And I guess the other
part of that is, is that something that should be shown to users and is that a
concept? Is there a way that you express that notion in a way that users can
understand it and make good choices? Or is it just something that your system makes a
choice on for all of your users? Herald: We have one more question.
Microphone number seven, please line up if you have any more. We still have a couple
of more minutes. Microphone number seven, please.
Question: Hi, Thanks for the talk. You talked about the private information
retrieval and how that would stop the server from knowing who retrieved the
message. But for me, the question is, how do I find out in the first place which
message is for me? Because if he, for example, always use message slot 14, then
obviously over a conversation, it would again be possible to deanonymize the users
in like, OK, they always accessing this one in like all those queries.
Answer: Absolutely. So I didn't explain that part. The trick is that between the
two people, we will share some secret, which is our conversation secret. And what
we will use that conversation secret for is to seed a pseudo random number
generator. And so we will be able to generate the same stream of random
numbers. And so each next message will go at the place determined by the next item
in that random number generator. And so now the person writing can just write out
random places as far as the server tells and when it wants to write the next
message in this conversation, it'll make sure to write at that next place
in its a random number generator for that conversation. There is a paper that will
describe a bunch more of that system. But that's the basic sketch.
A: Thank you. H: we have a question from the Internet.
Question: It seems like identity is the weak point of the new breed of messaging
apps. How do we solve this part of Zooko's triangle, the need for
identifiers and to find people? Answer: Identity is hard, and I think
identity has always been hard and will continue to be hard. Having a variety of
ways to be identified, I think remains important and is why there isn't a single
winner takes all system that we use for chat. But rather you have a lot of
different chat protocols that you use for different circles and different social
circles that you find yourself in. And part of that is our desire to not be
confined to a single identity, but to be able to have different facets to our
personalities. There are systems where you can identify yourself with a unique
identifier to each person you talk to rather than having a single identity
within the system. So that's something else that Pond would use. Was that the
identifier that you gave out to each separate friend was different. And so
you would appear as a totally separate user to each of them. It turns out that's
at the same time very difficult, because if I post an identifier publicly, suddenly
that identifier is now linked to me for everyone who uses that identifier. So you
have to give these out privately in a one on one setting, which limits your
discoverability. So that that concept of how we deal with identities I think is
inherently messy and inherently something that there's not going to be something
satisfying that solves. Herald: And that was the final question
concluding this talk. Please give a big round of applause for Will Scott.
Will: Thank you
*Postroll music*
subtitles created by c3subtitles.de in the year 2019. Join, and help us!