Return to Video

34C3 - Practical Mix Network Design

  • 0:00 - 0:16
    Music
    Herald: The next talk coming up is going
  • 0:16 - 0:21
    to be "Practical mix network designs,
    strong metadata protection for
  • 0:21 - 0:29
    asynchronous messaging", held by by David,
    who has done research on mix networks and
  • 0:29 - 0:36
    is a contributor to Tor network, and by
    Jeff, who has done contribution to the GNU
  • 0:36 - 0:40
    network project, organized a couple of
    sessions for this on last year's Congress
  • 0:40 - 0:46
    and is basically a mathematician, trying
    to get practical. they're going to talk
  • 0:46 - 0:55
    about components on mix networks and
    defenses that basically Tor can't do. And,
  • 0:55 - 1:03
    yeah. Welcome with a big round of
    applause, okay.
  • 1:03 - 1:12
    applause
    Jeff: Okay, so I'm Jeff, this is David,
  • 1:12 - 1:17
    we're going to be telling you some, we're
    going to be telling you some aspects about
  • 1:17 - 1:23
    designing mix networks. The, I'm involved
    with the I'm an academic involved with the
  • 1:23 - 1:31
    GNUnet project, he's involved with the
    Panoramix project. Okay, so first of all
  • 1:31 - 1:38
    we, just to be clear, of course encryption
    works, you know, if it's, you know,
  • 1:38 - 1:42
    properly implemented and then, you know,
    we have a huge amount of trust in it, we
  • 1:42 - 1:46
    we even have, you know, sort of slides
    showing that the most powerful adversaries
  • 1:46 - 1:51
    in the world can't can't can't break these
    things, so this is fine.
  • 1:51 - 1:57
    However we have to worry about sort of
    about the metadata leakage or and in this
  • 1:57 - 2:01
    talk we're specifically going to be
    worrying about traffic analysis of of
  • 2:01 - 2:09
    connections. inhales So, yeah, it's time
    to, it's time to actually start addressing
  • 2:09 - 2:15
    these things. Okay. So existing solutions
    to traffic analysis. So there's this
  • 2:15 - 2:22
    wonderful Tor Tor program and project and
    they we we know as of five years ago they
  • 2:22 - 2:29
    consider the the even the NSA considered
    considered Tor to be quite effective at
  • 2:29 - 2:36
    preventing mass location tracking. So this
    is, so Tor works for what it's designed to
  • 2:36 - 2:45
    do, Tor does not protect against an
    adversary who can see both ends of the Tor
  • 2:45 - 2:52
    circuit, so this this is this is a
    handicap in a number of situ- in a number
  • 2:52 - 2:59
    of situation, so the first situation is if
    if you have a website that is, if you if
  • 2:59 - 3:05
    you have a website of course then somebody
    can have fingerprinted this website in
  • 3:05 - 3:11
    advance, have some, you know, description
    of its of its traffic profile and they can
  • 3:11 - 3:15
    and they can tell if you're just from
    looking at your connection if you're if
  • 3:15 - 3:18
    you're accessing that that website over
    Tor.
  • 3:18 - 3:23
    So okay, so let's admit defeat for the web
    on the web for now, because we're not
  • 3:23 - 3:29
    going to, you know, we're not going to be
    able to provide that kind of, we're not
  • 3:29 - 3:34
    going to be able to defeat that kind of
    adversary very quickly. But okay, can we
  • 3:34 - 3:37
    just message our friends over Tor? So
    there's a few programs to do this: There's
  • 3:37 - 3:43
    Ricochet there's Briar; the problem with
    using Tor as a messaging as a messaging
  • 3:43 - 3:49
    transport layer is that frequently, the
    people you want to protect, are in the
  • 3:49 - 3:55
    same country or even on the same ISP, so
    the original property of, you know, the
  • 3:55 - 3:58
    adversary being able to see both sides of
    the connection comes comes through again
  • 3:58 - 4:01
    and they can very quickly be - that
    connection between them can very quickly
  • 4:01 - 4:08
    be seen. So okay, how can we actually keep
    our messaging metadata private? And the
  • 4:08 - 4:12
    answer we're going to say sort of - we're
    going to say the right one is a mixed
  • 4:12 - 4:14
    network.
    David: Oh yeah, so mixed networks are
  • 4:14 - 4:19
    message oriented, as opposed to stream
    oriented. They are essentially an
  • 4:19 - 4:27
    unreliable packet switching network. And
    also latency is added at each hop. This is
  • 4:27 - 4:35
    called a mix strategy; there's a bunch of
    different mix strategies. It's kind of an
  • 4:35 - 4:41
    architectural diagram. Notice there's no
    exit nodes, there's no talking to the web
  • 4:41 - 4:48
    like with Tor, so the security model is
    different, we do have a PKI, similar to
  • 4:48 - 4:57
    Tor, we we can call it like a directory
    authority system. So there's a bunch of
  • 4:57 - 5:04
    differences between Tor and mix nets and
    one of the important ones is that we can
  • 5:04 - 5:09
    actually do decoy traffic everywhere in
    this diagram, like we can do decoy traffic
  • 5:09 - 5:13
    all the way to clients or to the
    destination.
  • 5:13 - 5:21
    J.: Yeah so one of the one of the issues
    with Tor is of course you can't do you if
  • 5:21 - 5:27
    even if you wanted to add decoy traffic
    you couldn't hide the - you couldn't
  • 5:27 - 5:30
    protect against this website
    fingerprinting attack necessarily, because
  • 5:30 - 5:35
    you're going to be or you're still seeing
    the connection coming out the other side,
  • 5:35 - 5:39
    so you're see there's still a lot of
    analysis you can do. Okay so one thing,
  • 5:39 - 5:43
    just some history here, mixed networks are
    actually the the oldest anonymity system
  • 5:43 - 5:50
    as far as far as I know from David Chaum's
    1981 paper, then there's a few other tools
  • 5:50 - 5:55
    that have been proposed; one of them is
    private information retrieval, usually
  • 5:55 - 5:58
    written PIR.
    This works in sort of narrow situations,
  • 5:58 - 6:02
    when you're trying to retrieve something
    from some kind of database. The scaling
  • 6:02 - 6:08
    isn't perfect on it but there's cool
    things you can do. But there's another the
  • 6:08 - 6:12
    other the other one that sort of is
    generally proposed is the alternative to
  • 6:12 - 6:17
    mix networks is dining cryptographers
    networks. And the problem with them is
  • 6:17 - 6:25
    that the bandwidth is really literally,
    you know, each you're paying literally for
  • 6:25 - 6:31
    the quadratic cost per user, so I mean
    something like cubic. so the your
  • 6:31 - 6:38
    anonymity set is is is really going to
    wind up being very small and if you're
  • 6:38 - 6:43
    talking about building something that has
    inherently has a small anonymity set then
  • 6:43 - 6:49
    you have to "ask who are we protecting?"
    And, you know, if you're if - you're not
  • 6:49 - 6:53
    protecting whistleblowers anymore, because
    of whistle- if a whistleblower talks to,
  • 6:53 - 6:57
    you know, journalists and it's unclear
    which journalists, you know, Der Spiegel
  • 6:57 - 7:03
    he's talking to, well he's still some-
    he's still the guy with who knew this
  • 7:03 - 7:07
    thing, who talked to somebody at Der
    Spiegel. So and more as it does protect,
  • 7:07 - 7:12
    you know, it doesn't, you know, it the
    person that it does protect is somebody
  • 7:12 - 7:16
    who already has a lot of power and who
    it's gonna be hard to convict anyway be-
  • 7:16 - 7:21
    so what we want to do, so we really want
    to blow up the anonymity set as large as
  • 7:21 - 7:23
    possible and that's why we like mix
    networks.
  • 7:23 - 7:27
    D.: All right so we're gonna talk about a
    few attacks on mix networks and some
  • 7:27 - 7:33
    defenses. Epistemic attacks are not one of
    the attacks we're really going to focus on
  • 7:33 - 7:37
    because it's it's really a specialized
    area of research; there's actually a bunch
  • 7:37 - 7:45
    a few papers, written on breaking
    different public-key infrastructure
  • 7:45 - 7:50
    systems for like things like point-to-
    point networks and other other things like
  • 7:50 - 7:52
    that.
    J.: So, oh, so..
  • 7:52 - 7:59
    D.: Oh, so, okay, but we can say I guess
    we should mention that our PKI generally -
  • 7:59 - 8:06
    mix literature assumes you have a PKI, it
    assumes that the all the clients using it
  • 8:06 - 8:09
    somehow know about the whole network.
    J.: So
  • 8:09 - 8:13
    D.: Yeah, g...
    J.: So so usually when P - anonymity
  • 8:13 - 8:16
    researchers talk about a PKI, they
    generally assume something like the Tor
  • 8:16 - 8:19
    directory authority system, where you have
    some people, who can be very trusted, who
  • 8:19 - 8:23
    run the thing. This actually presents a
    scalability problem- it's what's goin- it's
  • 8:23 - 8:28
    what's the cuts(?) and post-project(?) and
    and ever- and Panoramix is doing; it does
  • 8:28 - 8:33
    present a scalability problem, more
    serious than the one for Tor. The there
  • 8:33 - 8:38
    are other ideas you can do, there's there,
    so on the try, on the idea
  • 8:38 - 8:42
    of sort of making it more secure beyond
    just these people, there's projects like
  • 8:42 - 8:47
    (???)thority and things and on the - but
    on trying to make it more scalable,
  • 8:47 - 8:51
    there's other things, like we have we have
    some people in the GNUnet project that are
  • 8:51 - 8:56
    researching this. In past generally these
    peer-to-peer networking projects to try
  • 8:56 - 9:01
    and come up with, you know, distributed
    PKI, had very serious attacks against
  • 9:01 - 9:05
    them; these epistemic and especially these
    epistemic attack types things, so and
  • 9:05 - 9:09
    you're not gonna completely fix those, so
    the way that you would have a distributed
  • 9:09 - 9:14
    PKI is you would have to prove that you
    really know how bad the attack is and then
  • 9:14 - 9:20
    argue that this is better than some nine
    people or whatever possibly being
  • 9:20 - 9:23
    compromised. But we don't want to talk too
    much about this, because this is not our
  • 9:23 - 9:26
    area of work but we just want to mention
    it's intr- it's a lot of interesting stuff
  • 9:26 - 9:32
    there and right now - so since we were
    leading from the epistemic attacks David's
  • 9:32 - 9:36
    gonna tell you about sort of, since this
    is sort of the sca- well, I'm sorry, he's
  • 9:36 - 9:40
    gonna tell you about how the scalability
    comes in.
  • 9:40 - 9:46
    D.: Yeah, so Tor, oh, so, sorry, mix nets
    can use cascade topologies where everyone
  • 9:46 - 9:52
    uses the same route and this is quite a
    different than tor where route
  • 9:52 - 9:59
    unpredictability is used to achieve some
    of it's anonymity properties. So in mixed
  • 9:59 - 10:04
    nets you can use the same route as
    everybody but this is a scalability
  • 10:04 - 10:13
    problem. So we have other things like free
    route and also stratified topology but
  • 10:13 - 10:18
    free route actually has slightly worse
    anonymity. Claudia Diaz has got an
  • 10:18 - 10:22
    excellent paper and about this.
    J.: Another kind of point about free route
  • 10:22 - 10:27
    is that in practice, like the Tor network,
    you visualize it as a free network and it
  • 10:27 - 10:32
    grew away from that. Nodes are authorized
    to be in specific positions and things
  • 10:32 - 10:36
    like this. So it may be that free routes
    aren't just... you wouldn't land there
  • 10:36 - 10:43
    anyway even if you tried
    D.: oh yeah. exit versus guard flags for
  • 10:43 - 10:51
    tor. This is another diagram of the... any
    layer, any mixin layer 0 can connect to
  • 10:51 - 10:59
    any mix in layer 1 and and send a mix
    packet. So this comes from the loop picks
  • 10:59 - 11:05
    design, we're gonna be mentioning some
    more designed from loop picks. The cool
  • 11:05 - 11:11
    thing about this is, it's fairly easy to
    calculate the entropy of each mix compared
  • 11:11 - 11:17
    to say free route, which is pretty
    complicated. This also scales pretty well,
  • 11:17 - 11:22
    we can add mixes to each layer if we need
    to scale up for more traffic and more
  • 11:22 - 11:26
    users.
    D.: So we're gonna mention a couple,
  • 11:26 - 11:31
    sometimes we'll put some citations on the
    slide. Don't take them.. they're not too
  • 11:31 - 11:36
    critical, but the one on this one... yeah,
    Claudia Diaz has a very nice paper for
  • 11:36 - 11:41
    understanding the different ideologies.
    J.: And I believe Roger has a paper on
  • 11:41 - 11:47
    this topic as well.
    D.: Ok, so why isn't this tor? Well, the
  • 11:47 - 11:51
    main thing that we can say is that tor
    doesn't actually mix. if the packets
  • 11:51 - 11:54
    are... The packets coming in at a
    particular point in time are basically the
  • 11:54 - 12:02
    same packets going out. You pretty much
    know within a very small number. So what a
  • 12:02 - 12:06
    mixed strategy actually does. This is an
    algorithm that's part of the software to
  • 12:06 - 12:11
    do the thing. What a mixed strategy
    actually does is it adds latency to reduce
  • 12:11 - 12:18
    the correlation between packets.
    And there's yeah ...
  • 12:18 - 12:26
    J.: So David Chum in 1981 with this first
    mix net paper describe this threshold mix.
  • 12:26 - 12:30
    So say this mix had a threshold of four.
    It would accumulate four input messages
  • 12:30 - 12:36
    like this. And when it had enough for its
    threshold, then it would shuffle them and
  • 12:36 - 12:41
    send them out. Mixes are also unwrapping a
    layer of encryption for each of these
  • 12:41 - 12:49
    hops. So if I was an attacker and I wanted
    to break this, what I could do is wait
  • 12:49 - 12:54
    until the mix is empty, or I could make
    that mix empty by sending my own messages
  • 12:54 - 12:59
    into it. And then when a target message
    enters this mix I could send my own
  • 12:59 - 13:04
    messages and cause it to achieve its
    threshold and shuffle and send all the
  • 13:04 - 13:09
    messages out. So then I would recognize
    all the cipher texts of my own messages
  • 13:09 - 13:11
    and the one message
    I don't recognize it's the
  • 13:11 - 13:16
    target message. You can keep doing this
    for each hop and this is called a
  • 13:16 - 13:21
    n-minus-1 attack or blending attack.
    There's a lot of variations on them. We
  • 13:21 - 13:27
    have continuous-time mixes like the stop-
    and-go mix and the poisson-mixed
  • 13:27 - 13:32
    strategies. These mixed strategies allow
    the client to select the delays for each
  • 13:32 - 13:41
    hop. Usually they're from an exponential
    distribution. If an attacker wants to
  • 13:41 - 13:48
    break this using a blending attack, first
    they need to empty the mix queue by
  • 13:48 - 13:52
    blocking all input messages from the mix
    and waiting some period of time where it's
  • 13:52 - 13:58
    highly probable that the mix queue would
    then be empty. Then they would allow their
  • 13:58 - 14:03
    one target message to enter the mix and
    continue to block other input messages and
  • 14:03 - 14:11
    then simply wait for that message to be
    outputted. Now these attacks we have some
  • 14:11 - 14:17
    defense for them, like say a heartbeat
    protocol from, George wrote a paper about
  • 14:17 - 14:23
    ten years ago, George Danezis. It's also
    in the Loopix paper as well, it's
  • 14:23 - 14:32
    mentioned. So we would have mixes with a
    kind of decoy traffic, we refer to him as
  • 14:32 - 14:36
    mixed loops or heartbeat traffic, where a
    mix is sending itself a message. It's like
  • 14:36 - 14:39
    a self-addressed stamped envelope. It's
    going through the mix network and coming
  • 14:39 - 14:46
    back. And if it doesn't receive its
    heartbeat in some time out, it knows it
  • 14:46 - 14:50
    could be under attack or of course there
    could be other problems in the network as
  • 14:50 - 14:57
    well. So you would want to maybe correlate
    a attack with several failures to receive
  • 14:57 - 15:03
    a heartbeat message.
    There's other defenses for blending
  • 15:03 - 15:06
    attacks as well. There was a recent paper
    published, but we're not going to talk
  • 15:06 - 15:15
    about that right now. The next category of
    attack is statistical disclosure attacks.
  • 15:15 - 15:20
    This is essentially, I like to think of it
    as the adversary is abstracting the entire
  • 15:20 - 15:26
    mix network as if it's one mix. They're
    looking at messages go in and messages
  • 15:26 - 15:32
    come out. A lot of this literature is
    written from the perspective of like
  • 15:32 - 15:36
    point-to-point networks. Like when Alice
    and Bob were receiving messages from the
  • 15:36 - 15:40
    mixed network they're receiving it at
    their home IP addresses, as if we had
  • 15:40 - 15:46
    publicly routable IP addresses and no NAT
    devices to get in the way. Maybe a more
  • 15:46 - 15:53
    modern sort of architecture might involve
    queuing messages. This is a concept used
  • 15:53 - 15:59
    in Loopix design as well.
    Loopix has got a bunch of different decoy
  • 15:59 - 16:06
    traffic types in order to add noise to the
    signal at various locations in the
  • 16:06 - 16:14
    network. So there's drop decoy traffic,
    where a client would select a random
  • 16:14 - 16:19
    destination provider to send a message to.
    So it traverses the mix net and then gets
  • 16:19 - 16:27
    dropped by the provider. And there's also
    client loops, and actually I should
  • 16:27 - 16:33
    mention, if we're doing these kind of
    statistical disclosure attacks, a lot of
  • 16:33 - 16:37
    this stuff we don't know how well it will
    work in the real world. Because, it really
  • 16:37 - 16:42
    depends on a specific application and the
    adversaries ability to predict users
  • 16:42 - 16:48
    behavior and that behavior should be
    repetitive. I mean this depends on how
  • 16:48 - 16:53
    much information is leaked by the system.
    But mix networks always leak information,
  • 16:53 - 17:00
    so it's it's about measuring the leakage
    and understanding if the user behavior is
  • 17:00 - 17:07
    dynamic enough.
    These attacks cannot always converge on
  • 17:07 - 17:14
    success. So it depends on the particular
    system and how it's tuned. In this
  • 17:14 - 17:20
    particular case for queuing messages in
    this style mixed network the adversary
  • 17:20 - 17:28
    would have to compromise the destination
    providers. So previously here in this
  • 17:28 - 17:32
    situation it would be, in this point-to-
    point network situation where people are
  • 17:32 - 17:38
    actually receiving messages from the mixed
    network to their mailbox directly or to
  • 17:38 - 17:45
    their home IP, the adversary is a passive
    adversary. In the more modern architecture
  • 17:45 - 17:50
    where messages are queued, I mean it's not
    more modern, but it's the Loopix design
  • 17:50 - 17:57
    which is a recent paper, so this attack
    becomes an active attack. And there's some
  • 17:57 - 18:02
    padding to the clients so we have some
    amount of receiver unobservability, so
  • 18:02 - 18:07
    clients received the same amount of
    information when they received messages.
  • 18:07 - 18:11
    D.: So okay, so there's a question that's
    natural. So we've talked about adding
  • 18:11 - 18:15
    latency and we are also talking about
    adding cover traffic. So you might ask "Is
  • 18:15 - 18:22
    this enough?" and "Could I get away with
    less?". And the answer to "Could I get
  • 18:22 - 18:33
    away with less?" seems to be no. At least
    by some artificial measures your anonymity
  • 18:33 - 18:39
    can't really scale better than the cover
    traffic times the latency. So one takeaway
  • 18:39 - 18:46
    from this is in the Tor, in what is Tor's
    situation, so I mean Roger always tells
  • 18:46 - 18:52
    people that they don't know, if adding
    cover traffic to Tor would help. And one
  • 18:52 - 18:55
    sort of extreme version of this is of
    course, whatever cover traffic you add
  • 18:55 - 19:04
    times something very small is still
    something rather relatively small. Now
  • 19:04 - 19:07
    you'll notice here of course the anonymity
    still looks quadratic in something but
  • 19:07 - 19:11
    it's still longer in the number of users.
    So what we're talking about is paying some
  • 19:11 - 19:16
    sort of fixed upfront cost. It may be
    somewhat large, part of it is in terms of
  • 19:16 - 19:20
    the users experience with the latency and
    part of it is in terms of the actual sort
  • 19:20 - 19:28
    of cost of their you know of their network
    connection, but you know, it's doable. So
  • 19:28 - 19:31
    one thing, so sometimes people have made
    these just to sort of wrap up this section
  • 19:31 - 19:36
    about topologies and whatever and
    strategies and things, so people have made
  • 19:36 - 19:41
    these sort of quasi religious statements
    about encryption from time to time. To
  • 19:41 - 19:46
    sort of boil that down to something
    concrete encryption is basically free in
  • 19:46 - 19:51
    general and but for the mixed network
    we're going to have to actually pay some
  • 19:51 - 19:56
    kind of real costs.
    Okay, so one thing about mix networks, you
  • 19:56 - 20:01
    don't want to roll your own packet format.
    There's this wonderful, first to know a
  • 20:01 - 20:06
    very reasonable one, it's sort of the one
    that has stopped much of the development
  • 20:06 - 20:11
    in this area, is Sphinx. It's quite
    compact, and it has a very nice security
  • 20:11 - 20:17
    proof, it's by George Danezis and Ian
    Goldberg. So just to comment on the name,
  • 20:17 - 20:21
    so the packet format has a header and a
    body and at the time that it was
  • 20:21 - 20:25
    developed, so the body has to be encrypted
    with what's called a wide block cipher. At
  • 20:25 - 20:28
    the time that was developed the only wide
    block cipher the people were thinking
  • 20:28 - 20:36
    about was lioness. There's now some other
    wide block ciphers like AEZ by Rogaway and
  • 20:36 - 20:42
    supposedly DJB has one on the way. So I'm
    gonna say a little few things about the
  • 20:42 - 20:47
    packet format. So the header has three
    parts, but one of them, the first part is
  • 20:47 - 20:53
    a public key this elliptic curve point,
    and then there's this body, which is
  • 20:53 - 20:58
    encrypted with a wide box cipher. So the
    way you think about this mix node n
  • 20:58 - 21:05
    operating is, Alice, you know there's this
    key exchange between the mix node and
  • 21:05 - 21:11
    Alice, that Alice first does it. She
    thinks up this is key for her packet and
  • 21:11 - 21:16
    does the exchange and then the mix node
    computes the other side of the Diffie-
  • 21:16 - 21:21
    Hellman. From that the mix node extracts
    the next hop and he has to mutate all of
  • 21:21 - 21:28
    the different things. So what Sphinx is,
    is the rules for how to mutate those. Okay
  • 21:28 - 21:33
    so let's say one thing, that's kind of
    important is: "Why are we using...", you
  • 21:33 - 21:38
    know "Why is this Delta...". I didn't make
    a comment on this too much, but the header
  • 21:38 - 21:42
    part was MACed and Delta was not. So why
    do we not put a MAC on Delta?
  • 21:42 - 21:46
    This seems very very dangerous. Of course
    if you know, if we had, if we were just
  • 21:46 - 21:53
    using an unMACed stream cipher than some
    adversary who controls a mix node next to
  • 21:53 - 21:58
    the sender and someplace where the message
    is going, could just XOR an arbitrary
  • 21:58 - 22:05
    message into the packet and then check for
    it when it arrives. But we don't use a
  • 22:05 - 22:11
    stream cipher, we use a wide block cipher.
    So what this means is, an attacker doing
  • 22:11 - 22:18
    the same sort of thing will get at most a
    one bit tagging attack. Okay, that's still
  • 22:18 - 22:25
    an attack. Why would we tolerate even a
    one bit tagging attack? And the answer is
  • 22:25 - 22:34
    that anonymous receivers really matter. So
    there's a few things, so of course a
  • 22:34 - 22:38
    journalistic source, some sort of
    whistleblower or whatever, but also any
  • 22:38 - 22:42
    kind of service, like if you want to talk
    to some crypto currency network, or you
  • 22:42 - 22:46
    want to talk to or download some file, or
    anything like this, anything where you
  • 22:46 - 22:52
    interact with a service or you need some
    kind of acknowledgment back of it. And in
  • 22:52 - 23:00
    fact even just the basic protocol acts for
    a messaging system need some sort of
  • 23:00 - 23:05
    reply. Okay, so what is this? So how do we
    do anonymous receivers? We create what's
  • 23:05 - 23:13
    called a single-use reply block, so that's
    a first node where it goes to, expiration
  • 23:13 - 23:21
    date, and then the header and one
    cryptographic key for one layer of it. And
  • 23:21 - 23:29
    so the recipient makes up this SURB and
    supplies it to the sender at some point in
  • 23:29 - 23:34
    the past. the sender attaches their Delta
    and they can send to the recipient.
  • 23:34 - 23:45
    Okay so great, now okay, now let's get
    into something tricky. We have these
  • 23:45 - 23:52
    common... Okay we might worry, so if you
    looked at the key exchange that I did,
  • 23:52 - 23:59
    Alice the sender just made up her alpha on
    the spot. So her key is ephemeral but the
  • 23:59 - 24:07
    mix node he wasn't. It was supplied by
    this PKI. So that means, so we want our
  • 24:07 - 24:11
    protocols to be forward secure and you
    know TOR is forward secure. It doesn't
  • 24:11 - 24:16
    negotiate, live negotiation with the top
    which is great. But we need some kind of
  • 24:16 - 24:24
    forward security and we don't have it, a
    priori. So what we have to do is well
  • 24:24 - 24:30
    first of all a mixed net, we need some
    kind of replay attack protection anyway.
  • 24:30 - 24:38
    So what this requires, some sort of data
    structure that will eventually fill up or
  • 24:38 - 24:44
    overflow or something like this. So to
    prevent that we have to do key rotation
  • 24:44 - 24:48
    anyway. So one option is to just rotate
    the mix node keys faster. The problem with
  • 24:48 - 24:52
    that is that you don't want to stress the
    PKI too much. Because the PKI is already a
  • 24:52 - 24:59
    scaling pain. So, okay. But another
    problem with that is that these SURB
  • 24:59 - 25:04
    lifetimes are equal to the node key life,
    they can't exceed the node key lifetimes.
  • 25:04 - 25:10
    So that means that we, if we want to be
    able to have our forward, have our key
  • 25:10 - 25:15
    compromise window smaller than the node
    key lifetimes or then we have to do, or -
  • 25:15 - 25:20
    you know smaller than the server lifetimes
    - and we have to do something else. So
  • 25:20 - 25:25
    there's a couple ideas. So George, back in
    two thousand th- so, okay the idea is;
  • 25:25 - 25:30
    Okay, maybe we can be like, a little like
    Tor and use more packets per for the
  • 25:30 - 25:35
    packet we want to send but not do it in
    the way Tor does it. So George proposed
  • 25:35 - 25:41
    using two packets in different key epochs.
    That's pretty good, that that gives you,
  • 25:41 - 25:46
    that gives you a lot of nice properties.
    So there's another thing you can do that
  • 25:46 - 25:51
    I'm sort of, that I've been working on,
    which is you can you can use a loop to the
  • 25:51 - 25:58
    mix, to a mix node to actually do a key
    exchange and then on the mix node you can
  • 25:58 - 26:05
    you can use a double ratchet construction
    for some hops. And that the this, problem
  • 26:05 - 26:11
    with this is it's cheating, these two
    these two things. and you wouldn't want to
  • 26:11 - 26:17
    do them at all hops, because they create
    some correlations between packets. So,
  • 26:17 - 26:23
    okay, so we can so we can, in general we
    can ask what is what do we want the key
  • 26:23 - 26:29
    exchange that our mix node - what do we
    want, how do we make this mix node forward
  • 26:29 - 26:33
    secure, so I don't want to say too much
    about this but in general we can talk
  • 26:33 - 26:40
    about the different stra- different sort
    of basic technologies for key exchanges
  • 26:40 - 26:44
    and the properties we can get out of them
    in the context of Sphinx.
  • 26:44 - 26:48
    And, you know, anything that's based on
    elliptic curves is not going to be post
  • 26:48 - 26:53
    quantum, so if we want something based on,
    you know, if we want that then we need to
  • 26:53 - 26:56
    something else so there was a blinding
    operations in Sphinx I didn't tell you
  • 26:56 - 27:00
    about, doing that in the post quantum
    context is tricky. Probably it works for
  • 27:00 - 27:06
    SIDH. We don't know if it works for LWE.
    We certainly have no idea how to do it
  • 27:06 - 27:11
    efficiently, maybe it can be done. Our
    cheating strategy gives us nice key
  • 27:11 - 27:16
    erasure properties, it gives us post
    quantum, if the loop if the loop did a
  • 27:16 - 27:21
    post quantum key exchange and there's
    another nice property that it gives, that
  • 27:21 - 27:25
    you can't really get any other way, which
    is that it the the blinding thing is
  • 27:25 - 27:30
    hybrid - you can actually have a hybrid
    post quantum property, and that means that
  • 27:30 - 27:34
    you can use both an elliptic curve and
    this post quantum key exchange and if
  • 27:34 - 27:39
    either one of them is good then you can't
    break then you can't break it. If you try
  • 27:39 - 27:44
    and do this construction with something
    like LWE you're probably not going to be
  • 27:44 - 27:47
    able to get that hybrid post quantum
    property, 'cause the blinding operation
  • 27:47 - 27:51
    itself will depend on the LWE
    cryptographic assumptions.
  • 27:51 - 27:58
    So nevertheless I want to conjecture that
    LWE (?????????) LWE means "learning with
  • 27:58 - 28:04
    errors", may be the eventual sort of post
    quantum key exchange we want to use and so
  • 28:04 - 28:08
    mathematicians love conjectures, so I
    don't think there's one with blinding but
  • 28:08 - 28:15
    I think we can probably come up with
    something that eventually, where we have
  • 28:15 - 28:20
    some kind of nice blinding for the an LWE
    scheme and it even has puncturing.
  • 28:20 - 28:23
    Punctured encryption is something that you
    can currently do with pairing based crypto
  • 28:23 - 28:31
    and it's excruciatingly slow but I think
    it could, I suspect it could be done much
  • 28:31 - 28:37
    faster with LWE. Okay
    D.: Okay, so mix networks: they're
  • 28:37 - 28:44
    unreliable, they're packet switching, so
    in that case some classical Network
  • 28:44 - 28:52
    literature can can be applied. Now an
    automatic repeat request protocol scheme
  • 28:52 - 28:57
    is one of those protocol schemes that has
    protocol acknowledgments and retransmits
  • 28:57 - 29:02
    and we can do this over mix networks but
    it leaks extra information. Every ACK you
  • 29:02 - 29:08
    send could potentially be used as in a
    correlation attack, for instance if the
  • 29:08 - 29:13
    adversary causes the ACK packet to be
    dropped. And in a stopping way ARQ(?) the
  • 29:13 - 29:18
    simplest variety of these protocols, would
    leak the least amount of information, so
  • 29:18 - 29:27
    that's what we're using and we have three
    cryptographic layers in our stack right
  • 29:27 - 29:35
    now in this Loopix Katzenpost project
    we're working on. Yawning(?) angel wrote a
  • 29:35 - 29:42
    cryptographic link layer based on the
    noise cryptographic framework. He's mixing
  • 29:42 - 29:50
    new hope simple(?) with x25509 and the key
    exchange and we also have a Sphinx
  • 29:50 - 29:56
    cryptographic layer. Sphinx is what Jeff
    talked about earlier, the cryptographic
  • 29:56 - 30:02
    packet format and we also have an end-to-
    end cryptographic messaging. And this is
  • 30:02 - 30:09
    another sort of Loopix style diagram:
    Alice sends message to Bob's provider, so
  • 30:09 - 30:15
    it goes through the mix network to Bob and
    Bob can retrieve his message later and
  • 30:15 - 30:21
    with some relatively simple changes from
    this Loopix design, we can, to have
  • 30:21 - 30:27
    stronger location hiding properties, where
    Alice and Bob don't talk directly to the
  • 30:27 - 30:32
    provider that they're retrieving messages
    from. They can send single-use reply
  • 30:32 - 30:38
    blocks to retrieve messages this would
    increase latency.
  • 30:38 - 30:40
    J.: So one thing that's nice there's a
    comment to make here, is that a lot of
  • 30:40 - 30:46
    time certain schemes in academia tend to
    use, want to use PIR for this retrieving,
  • 30:46 - 30:53
    the the thing I thought from your from
    your provider and then the - one of the
  • 30:53 - 30:58
    problems with using a PIR scheme here is
    that you're gonna have very different very
  • 30:58 - 31:03
    different sort of assumptions at play
    there and the way even what you model it
  • 31:03 - 31:08
    is going to be necessary necessarily quite
    complex. It's probably fun if you're a
  • 31:08 - 31:11
    graduate student, you know, doing, playing
    with all this stuff but it's actually
  • 31:11 - 31:17
    giving all of everything to match up will
    be complicated. So this is why, so in the
  • 31:17 - 31:21
    scheme they were talking about here you
    actually, you're your mix net is giving
  • 31:21 - 31:25
    you your location hiding property so you
    can you can extract some similar things.
  • 31:25 - 31:30
    D.: Well, right and also, whereas in this
    situation, with a Loopix design it doesn't
  • 31:30 - 31:36
    have strong location hiding properties, in
    particular if Alice really wanted to
  • 31:36 - 31:42
    figure figure out where Bob is she would
    hack his provider and then stake it out
  • 31:42 - 31:47
    until his IP address showed up again or so
    -
  • 31:47 - 31:52
    J.: One problem with this, with these
    provider models, is that, like David just
  • 31:52 - 32:01
    said, you can get your provider hacked and
    there's a way to fix that. It requires
  • 32:01 - 32:04
    modifying Sphinx a bit, I said, I know
    that we just said don't roll your own
  • 32:04 - 32:08
    packet format but it's a good idea to go
    through the security proof again anyway
  • 32:08 - 32:15
    and it's a small change. But, so, the idea
    is that we have, in this middle, this
  • 32:15 - 32:21
    harddrive picture, is is some sort of of
    mailbox server or cumulation thing, that
  • 32:21 - 32:27
    the receiver here can move whenever he
    wants without telling his contacts. And
  • 32:27 - 32:32
    his contacts actually reach him in other
    ways; either he gives them SURBs or he
  • 32:32 - 32:35
    sub- puts the SURBs at this thing called a
    crossover point, which I didn't want to
  • 32:35 - 32:43
    tell you too much about. So, but the the
    idea is that this guy can, our receiver
  • 32:43 - 32:49
    can supply the - he can send some SURBs to
    this point in the middle and then the
  • 32:49 - 32:56
    pack- and when he goes online - and then
    it will send him messages, so the you can
  • 32:56 - 33:00
    have this ver- this decoupling and one of
    the nice things - so at the end of the day
  • 33:00 - 33:04
    what the proof, what's your like security
    result for the mix net's going to be, is
  • 33:04 - 33:08
    like, okay well, in three months - you
    know they're not going to be able to
  • 33:08 - 33:13
    deanonymise you in three months. So we may
    be able to do a bit more if we can move
  • 33:13 - 33:20
    this guy in the middle periodically.
    Okay, so but this is work, very much work
  • 33:20 - 33:23
    in progress, it's not at all in the cuts
    and post thing and it requires modifying
  • 33:23 - 33:29
    Sphinx and doing doing some redoing a
    number of proofs. So, okay, we've been
  • 33:29 - 33:36
    talking about applications with the idea
    being messaging. There's other
  • 33:36 - 33:41
    applications and - where you're still
    sending messages but to give you a bit
  • 33:41 - 33:47
    more, something a bit more concrete:
    There's a there's a few schemes for doing
  • 33:47 - 33:49
    anonymous money, well right now there's a
    lot of schemes for doing anonymous money
  • 33:49 - 33:52
    and mostly they suck but there's a few
    that are actually quite good and have
  • 33:52 - 33:58
    extremely strong cryptographic assurances
    on their anonymity: Zcash you basically
  • 33:58 - 34:01
    would have to invert a hash function or
    something to break it, I'm not completely
  • 34:01 - 34:08
    sure, Taler, well in in the RSA blind
    signatures have information theoretically
  • 34:08 - 34:10
    secure blinding, which means they are
    absolutely unbreakable.
  • 34:10 - 34:12
    There's a point in Taler where it's weaker
  • 34:12 - 34:19
    than that, but another thing you might ask
    is, you know, can we do anything web-like.
  • 34:19 - 34:24
    Well, there's a project that wants to like
    package up web pages and ship them over
  • 34:24 - 34:30
    free nets, so you could use it to ship
    things over a mix network. But,
  • 34:30 - 34:34
    fundamentally, if you imagine what we want
    to do is like build build some application
  • 34:34 - 34:37
    that does some collaborative thing like
    run something like Google Wave or have a
  • 34:37 - 34:42
    have just an etherpad over a mix network,
    you're gonna have the interesting issues
  • 34:42 - 34:48
    that pop up with like the merges and other
    thing and, and anyway the latency is gonna
  • 34:48 - 34:53
    have other impacts on the users. And one
    things we're not really thinking about but
  • 34:53 - 34:59
    we would really like other people to think
    about is sort of how to make how to make
  • 34:59 - 35:08
    people happy with higher latency
    applications. And this sounds hard, but
  • 35:08 - 35:12
    actually a lot of times, like, you know
    when you look at people who are developing
  • 35:12 - 35:16
    more modern web frameworks, actually they
    are doing you know more of the abstract
  • 35:16 - 35:23
    alike something like couch TV is doing;
    it's not literally, you know, supporting
  • 35:23 - 35:27
    latency, but it's it's decoupling things
    in a way that it is quite relevant to what
  • 35:27 - 35:30
    we want to do.
    D: So, but it wouldn't be fair for us to
  • 35:30 - 35:35
    say, like, "hey, use this cool messaging
    app - it's unreliable, so I'm gonna send
  • 35:35 - 35:41
    you a message, but you might not get it."
    So we want to definitely build in some
  • 35:41 - 35:47
    reliability, and and you and you pay for
    that in in retransmission some times and
  • 35:47 - 35:51
    and some extra leaked information for
    which we need to compensate with more
  • 35:51 - 35:56
    decoy traffic. We can actually -- the
    Loopix paper explores this trade-off where
  • 35:56 - 36:00
    you can make the latency lower in a mixed
    network if you are willing to send more
  • 36:00 - 36:06
    decoy traffic. And so that should help.
    J: Yeah
  • 36:06 - 36:11
    D: It's it would still it still doesn't
    make mix networks, I don't think as low
  • 36:11 - 36:19
    latency as tor or even close. But this is
    a matter of tuning, and we can at least
  • 36:19 - 36:23
    have lower latency mix networks than say,
    10 years ago.
  • 36:23 - 36:25
    J: One of the nice things about certainly
    the nice things about the stuff that
  • 36:25 - 36:29
    David and Yawning have been doing is that
    they're they're active really trying to
  • 36:29 - 36:40
    make the - the the, sorry, the reliability
    measures work in the mixed work in the --
  • 36:40 - 36:43
    or just just above the mix network. And
    this is really essential if you want to
  • 36:43 - 36:48
    build something that application
    developers can use because one it is
  • 36:48 - 36:54
    actually common in anonymity systems for
    the sort of reliability measures to create
  • 36:54 - 36:59
    to possibly compromise other things. So
    having being able to do the reliability
  • 36:59 - 37:04
    stuff in a way that you can still have
    your security properties for it is
  • 37:04 - 37:09
    important. Okay.
    D: Oh yeah, we'd like to say thanks to the
  • 37:09 - 37:14
    researchers we've been working with. And I
    like to thank Yawning Angel for all the
  • 37:14 - 37:20
    good design advice and work on the
    specifications. And and for George for his
  • 37:20 - 37:22
    advice.
    J: George and Claudia are always one
  • 37:22 - 37:25
    D: For their excellent paper. Anya for her
    Loopix paper.
  • 37:25 - 37:27
    J: Christian I've - everything that I've
    been working on our talk to Christian
  • 37:27 - 37:30
    about all the time
    D: Nick Matheson from the Tor project
  • 37:30 - 37:35
    helped me out a lot with the with our PKI
    specification because, well, I mean he
  • 37:35 - 37:39
    wrote the directory authority system for
    mix minion, and for tor, and
  • 37:39 - 37:43
    J: And also to Trevor Perrin for running
    this wonderful mailing list which where we
  • 37:43 - 37:46
    get all where we get numbers
    of important ideas.
  • 37:46 - 37:52
    D: Ah yeah and Trevor also helped with our
    PKI sense so that was really great; with
  • 37:52 - 37:58
    our wire protocol using noise, I mean.
    Anyway and that's that's the this new sort
  • 37:58 - 38:03
    of project. Alright, that's it.
  • 38:03 - 38:13
    Applause
  • 38:13 - 38:18
    Herald: Thank you so much, if you have any
    questions here in the room, please line up
  • 38:18 - 38:25
    at the microphones. Do we have questions
    from the internet? From the IRC Network?
  • 38:25 - 38:31
    No questions from the IRC. There's one
    question microphone one
  • 38:31 - 38:36
    Mic 1: You mentioned latency will be
    higher than tor - should we be thinking
  • 38:36 - 38:41
    sort of seconds, minutes,
    what's the sort of order of
  • 38:41 - 38:44
    J: We don't know
    D: Oh yes so the question is, the latency
  • 38:44 - 38:49
    will be higher than tor, how how high will
    it be? We don't really know until we tune
  • 38:49 - 38:53
    the mix Network and we're not
    J: George has claimed seconds so I don't
  • 38:53 - 38:56
    know if I believe him
    D: I should start off by saying that mix
  • 38:56 - 38:59
    networks aren't trying to be a general-
    purpose anonymity system like tor. We're
  • 38:59 - 39:04
    trying to make customized networks for
    specific applications, and so each
  • 39:04 - 39:09
    application has different traffic patterns
    in different ways they're used. So the
  • 39:09 - 39:17
    latency would would necessarily come after
    tuning. Now, some, we have some idea that
  • 39:17 - 39:23
    maybe a few minutes, let's say. But it;
    really I can't answer the question yet.
  • 39:23 - 39:28
    Actually the researchers were working with
    are about to publish a new paper about how
  • 39:28 - 39:36
    to tune decoy traffic and latency for the
    desired entropy you want in each mix,
  • 39:36 - 39:41
    yeah.
    Herald: Microphone number two, your
  • 39:41 - 39:45
    question?
    Mic 2: You have mentioned that the in
  • 39:45 - 39:51
    mixed networks PKI's have higher
    scalability problems than in Tor - why is
  • 39:51 - 39:55
    that? It looks like the mix Network will
    have less nodes because the you don't need
  • 39:55 - 39:59
    route unpredictability, so
    J: I mean if you're trying to build a
  • 39:59 - 40:03
    replacement for email and you want
    everyone in the world to use it, if you
  • 40:03 - 40:10
    work through like, a sort of very bullshit
    back of the envelope computation -
  • 40:10 - 40:18
    there's an argument that your that if you
    have a central that a centralized PKI plus
  • 40:18 - 40:23
    whatever other anonymity system is only
    about 10 million times better than just
  • 40:23 - 40:28
    sending every message to everybody.
    Something, you know, that's very back of
  • 40:28 - 40:37
    the envelope you can try and work. So you
    need; yeah well okay so there's that, and
  • 40:37 - 40:42
    and the the specific seeing when I said
    it's less of a problem for tor, is that
  • 40:42 - 40:44
    tor can do certain clever
    things like there's a,
  • 40:44 - 40:47
    there's one of their proposals I think is
    actually not taking that seriously at the
  • 40:47 - 40:52
    moment is where they published this big
    list - they published the PKI or sorry,
  • 40:52 - 40:58
    the big the the thing and nodes don't
    actually download the whole, the the whole
  • 40:58 - 41:02
    consensus at all. They just point to a
    place in the consensus and they get back a
  • 41:02 - 41:06
    proof that they were given the correct
    that they were forwarded to the correct
  • 41:06 - 41:10
    node. So this might this then gives you
    another order of magnitude or two on that
  • 41:10 - 41:16
    fat on that you know 10 million
    I just quoted you.
  • 41:16 - 41:22
    Herald: Okay, microphone number three
    Mic 3: Hi, this is looks like really good
  • 41:22 - 41:27
    work and I'm happy to see it - now my
    question is if there are multiple
  • 41:27 - 41:31
    applications which have different tuning
    requirements, can they share the same
  • 41:31 - 41:34
    network and help each others anonymity
    set, or do we have to have multiple
  • 41:34 - 41:39
    networks?
    D: Ah, so we agree it would be best if
  • 41:39 - 41:43
    they could help each other by increasing
    each other's anonymity set. But we're
  • 41:43 - 41:49
    concerned that the specific tuning for the
    decoy traffic might prohibit this in some
  • 41:49 - 41:54
    cases. For -- actually, and there's some
    other considerations as well, so since
  • 41:54 - 42:00
    we're not stream oriented, all the data
    has to fit in one packet. And so if we
  • 42:00 - 42:04
    have like an email use case, we probably
    are gonna get around 50 K average size
  • 42:04 - 42:10
    emails, let's say. And if we want to make
    like mix chat or Katzen chat application,
  • 42:10 - 42:16
    I might send really short messages like,
    "yo what's up", and now we're sending that
  • 42:16 - 42:20
    in a big 50 K a packet.
    J: So, one thing that is clear - if you
  • 42:20 - 42:23
    wouldn't do it for all, think you wouldn't
    have a new thing for every application.
  • 42:23 - 42:26
    Obviously if you have something that's
    gonna be quite infrequent like a payment
  • 42:26 - 42:32
    thing, then it needs then you should be
    using a network with with much more
  • 42:32 - 42:36
    frequent packets and just accept that
    you're gonna be you -- accept though the
  • 42:36 - 42:41
    inefficiency. D: And there's another
    consideration too - it, which is,
  • 42:41 - 42:45
    sometimes in these chat applications,
    communication partnerships might be
  • 42:45 - 42:49
    symmetrical in that we
    might send each other roughly the same
  • 42:49 - 42:54
    amount of data. And and stuff that, like
    not that I don't think mix Nets are good
  • 42:54 - 42:58
    for web browsing, but in stuff like the
    web it's more like "get to page" and then
  • 42:58 - 43:02
    you get a bunch of information back. So
    there's a lot of different; so what would
  • 43:02 - 43:08
    the decoy traffic look like that versus a
    symmetrical communication partnership. So
  • 43:08 - 43:13
    that's what I meant by some applications
    might not be compatible with each other to
  • 43:13 - 43:17
    tune this decoy traffic
    J: Yeah we certainly would hope that most
  • 43:17 - 43:22
    sort of like peer-to-peer, that, you know
    most sort of peer-to-peer like all of your
  • 43:22 - 43:26
    etherpad, your other sort of collaborative
    applications, your email, your payment
  • 43:26 - 43:29
    network - we'd certainly hope that all
    that stuff could be bundled onto one thing
  • 43:29 - 43:34
    that was sort of optimized for this email-
    like use case. And then whether if you
  • 43:34 - 43:41
    actually need the instant messaging
    network at all is another question.
  • 43:41 - 43:45
    Herald: All right, microphone number one
    what's your question?
  • 43:45 - 43:49
    Mic 1: Um, can you give well can you give
    more concrete examples of software to try
  • 43:49 - 43:55
    out or like, so like like papers are
    great, like is there anything to touch to
  • 43:55 - 43:58
    act to, whatever
    D: Well well, I mean, actually right now
  • 43:58 - 44:03
    we're running a test mix Network on
    several machines that we had lying around,
  • 44:03 - 44:08
    and it works great - thanks for (meskhi
    oh) and (kali) for their help for that.
  • 44:08 - 44:14
    But, we don't really have any anything
    near production-ready, like
  • 44:14 - 44:21
    J: Yeah the stuff I was talking about
    doesn't even work.
  • 44:21 - 44:28
    D: So the answer to question is: no, we
    got nothing. But but we hope we hope soon.
  • 44:28 - 44:32
    Like, I'm not sure how soon, but
    J: Depends on funding, depends on other
  • 44:32 - 44:38
    things: we're working on it.
    Herald: Thank you, microphone two: what is
  • 44:38 - 44:41
    your question?
    Mic 2: I was thinking about this in the
  • 44:41 - 44:47
    real world - you're envisioning an app
    where people can communicate, and I worry
  • 44:47 - 44:55
    about mobile telephones because; let's
    envision two users using this app to
  • 44:55 - 44:59
    communicate with each other. The idea
    would be that one person sends a message
  • 44:59 - 45:02
    and then sometime later this
    other person takes their phone out
  • 45:02 - 45:06
    of their pocket. There is so much going
    on when a phone comes out of a pocket and
  • 45:06 - 45:12
    as the screen is turned on. WhatsApp is
    talked to; there's so much that that you
  • 45:12 - 45:17
    can look at outside of this whole mix
    Network that if you, over a month of time,
  • 45:17 - 45:22
    can correlate who picks their phone out of
    their pockets every time when, when person
  • 45:22 - 45:26
    sends a message. So can't you correlate
    that way and isn't that a huge problem
  • 45:26 - 45:30
    that, that sort of is completely outside
    of the world of the of the problems you're
  • 45:30 - 45:35
    thinking about.
    J: My, in my ideal; I have no idea. In my
  • 45:35 - 45:40
    ideal world the part of the solution to
    making the users happier with latency is
  • 45:40 - 45:45
    the phone doesn't ding anymore. You don't
    get notifications - you check your phone
  • 45:45 - 45:52
    when you check your phone.
    Mic 2: Sorry, I think that would be an
  • 45:52 - 45:56
    important security property as well.
    J: But I would actually like it there's a
  • 45:56 - 46:00
    question here is: would that make people
    actually happier with latency? What can
  • 46:00 - 46:03
    you, I mean, you you know all of these
    things that are being built now are being
  • 46:03 - 46:08
    built to sort of maximize engagement. And
    you want to actually, you actually don't
  • 46:08 - 46:11
    want to do that anymore. You want people
    to only use it when they want to you know
  • 46:11 - 46:19
    when they want to use it.
    Herald: All right, thank you. Seems there
  • 46:19 - 46:24
    are no further questions, so thanks a lot
    to Jeff, thanks a lot to David
  • 46:24 - 46:35
    Applause
  • 46:35 - 46:40
    Music
  • 46:40 - 46:52
    subtitles created by c3subtitles.de
    in the year 2018. Join, and help us!
Title:
34C3 - Practical Mix Network Design
Description:

more » « less
Video Language:
English
Duration:
46:52

English subtitles

Revisions Compare revisions