3 ms·

> In practice, the message latency would be around 20s to 40s, depending on security parameters and the number of users connected to the system. Haven't had ti

> In practice, the message latency would be around 20s to 40s, depending on security parameters and the number of users connected to the system. Haven't had time to read the paper yet - is this an inherent property of the system, or a number that could be reduced by future work?

LoSboccacc 11y ago
seems inherent - servers operate in rounds and each round carries legit traffic plus enough noise to allow traffic metadata to drown in nothingness and forward it to a whole server chain to avoid an adversary to control all the servers, so as you scale servers need more time to forward and mixin traffic
- deanCommie 11y ago
  Could someone much smarter than me do some napkin math and figure out roughly what kind of tradeoff in security you make by limiting the noise? 20-40 seconds is fine if you are releasing NSA secret files and want the chance of metadata discovery to be <0.1% (number made up) But it's too much to use as a regular form of conversation between average parties who just want to set a precedent that all conversations by default should be un-monitorable. However what if that number was down to ~5 seconds? Now it's tolerable. But the tradeoff is, what does the chance of detectability go up to? 1%? 5%? 50%?
  - creshal 11y ago
    > 20-40 seconds is […] too much to use as a regular form of conversation between average parties With the current irc-ish UI the latency would clash with user expectations, but e-mail, message boards and quite a few other forms of communication regularly deal with much higher latencies. I suppose it depends on how you market it.
    - mc808 11y ago
      I'll create a GUI interface using Visual Basic that prints Tracking IP address ... [30 seconds] ... Failed! Message delivered!
  - LoSboccacc 11y ago
    you can have x "message" sent per round, where a message is a packet (a line can be split over multiple packets) and x must remain constant and in the implementation is 1. now the problem is, the adversary modelled here is one that can drop a node out of the network and see if any other node message frequency drops. that's why traffic, noise and latency are strictly correlated. if a conversation suddenly drop you have to make sure that the noise level doesn't drop, and vice versa. when you start a conversation you need to tune down the noise, to maintain the frequency. thus the more noise you generate the more packet you can send when you need it, but the more the load on the servers. it's not about hiding the message in the noise (that's tor model) it's about making messages statistically indistinguishable. for that there is no confidence interval, you need to send random noise out, randomly, at a fixed randomized frequency. now I think they don't actually send a message every round, but do generate noise and messages interlocked so that the frequency remains constant. that frequency must be slower than rounds frequency and you cannot really tune it in the way you're suggesting. There might be probably other way to relax the confidence, but it might have impacts on other clients on the network, even those unrelated to your conversation. also, under this round model, if a client drop after handshaking and before collecting the message the message for that handshake is lost (no retransmission and no chance to pick it up later)
  - lazard 11y ago
    The slides toward the end of my talk [1] try to give some intuition for Vuvuzela's security in terms of "jury certainty". [1] https://davidlazar.org/slides/vuvuzela-sosp2015.pdf https://davidlazar.org/slides/vuvuzela-sosp2015.pdf
lazard 11y ago
Author here: The latency can be reduced by future work. For example, Section 9 in the paper mentions an idea for reducing the amount of noise (and thus reducing latency) by treating honest users as noise. Vuvuzela can also be configured with a smaller "privacy budget" to reduce latency.

LoSboccacc 11y ago

seems inherent - servers operate in rounds and each round carries legit traffic plus enough noise to allow traffic metadata to drown in nothingness and forward it to a whole server chain to avoid an adversary to control all the servers, so as you scale servers need more time to forward and mixin traffic

deanCommie 11y ago
Could someone much smarter than me do some napkin math and figure out roughly what kind of tradeoff in security you make by limiting the noise? 20-40 seconds is fine if you are releasing NSA secret files and want the chance of metadata discovery to be <0.1% (number made up) But it's too much to use as a regular form of conversation between average parties who just want to set a precedent that all conversations by default should be un-monitorable. However what if that number was down to ~5 seconds? Now it's tolerable. But the tradeoff is, what does the chance of detectability go up to? 1%? 5%? 50%?
- creshal 11y ago
  > 20-40 seconds is […] too much to use as a regular form of conversation between average parties With the current irc-ish UI the latency would clash with user expectations, but e-mail, message boards and quite a few other forms of communication regularly deal with much higher latencies. I suppose it depends on how you market it.
  - mc808 11y ago
    I'll create a GUI interface using Visual Basic that prints Tracking IP address ... [30 seconds] ... Failed! Message delivered!
- LoSboccacc 11y ago
  you can have x "message" sent per round, where a message is a packet (a line can be split over multiple packets) and x must remain constant and in the implementation is 1. now the problem is, the adversary modelled here is one that can drop a node out of the network and see if any other node message frequency drops. that's why traffic, noise and latency are strictly correlated. if a conversation suddenly drop you have to make sure that the noise level doesn't drop, and vice versa. when you start a conversation you need to tune down the noise, to maintain the frequency. thus the more noise you generate the more packet you can send when you need it, but the more the load on the servers. it's not about hiding the message in the noise (that's tor model) it's about making messages statistically indistinguishable. for that there is no confidence interval, you need to send random noise out, randomly, at a fixed randomized frequency. now I think they don't actually send a message every round, but do generate noise and messages interlocked so that the frequency remains constant. that frequency must be slower than rounds frequency and you cannot really tune it in the way you're suggesting. There might be probably other way to relax the confidence, but it might have impacts on other clients on the network, even those unrelated to your conversation. also, under this round model, if a client drop after handshaking and before collecting the message the message for that handshake is lost (no retransmission and no chance to pick it up later)
- lazard 11y ago
  The slides toward the end of my talk [1] try to give some intuition for Vuvuzela's security in terms of "jury certainty". [1] https://davidlazar.org/slides/vuvuzela-sosp2015.pdf https://davidlazar.org/slides/vuvuzela-sosp2015.pdf

lazard 11y ago

Author here: The latency can be reduced by future work. For example, Section 9 in the paper mentions an idea for reducing the amount of noise (and thus reducing latency) by treating honest users as noise. Vuvuzela can also be configured with a smaller "privacy budget" to reduce latency.