3 ms·

That's kind of the point of Sealed Sender. If you block delivery of a message, you have no idea who it's for or from.

grayhatter 2y ago
from signal > Without authenticating, hand the encrypted envelope to the service along with the recipient’s delivery token. I'm probably going to need to read the white paper to actually understand this, because currently I'm confused as to how this doesn't result in knowing the destination. Surely I can reverse the delivery token if I'm in control of the servers? but I was thinking network based disambiguation edit; seems there's (maybe was?) a number of ways to disambiguate targets, users, and contact graphs https://www.ndss-symposium.org/ndss-paper/improving-signals-sealed-sender/ https://www.ndss-symposium.org/ndss-paper/improving-signals-...
- some_furry 2y ago
  I should be more precise: Signal's server doesn't know who sent the message, since that information was Sealed. Signal's server does know where to deliver the message to, based on a 96-bit random value generated client-side by the recipient (the delivery token). But it cannot know which user has which delivery token. To understand that, you need to look at the zero-knowledge credentials section of the code. They could randomly drop messages sent to a specific targeted user's delivery token and block messages sent to that targeted user, but they have no way of knowing which user they're targeting. (Also, the client could just enroll a new one if this ever happened and Signal was somehow court-ordered to block delivery to a specific delivery token.)
  - grayhatter 2y ago
    Is signal not able to tag and reduce the sealed envelope to a "final" destination network address? I.e. is a sender able to prove that it's impossible for signal servers to do this?
    - some_furry 2y ago
      I don't understand your question. See https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ and https://eprint.iacr.org/2019/1416 https://eprint.iacr.org/2019/1416 if you'd like descriptions for the protocols I'm trying to describe in HN comments.

from signal > Without authenticating, hand the encrypted envelope to the service along with the recipient’s delivery token. I'm probably going to need to read the white paper to actually understand this, because currently I'm confused as to how this doesn't result in knowing the destination. Surely I can reverse the delivery token if I'm in control of the servers? but I was thinking network based disambiguation edit; seems there's (maybe was?) a number of ways to disambiguate targets, users, and contact graphs https://www.ndss-symposium.org/ndss-paper/improving-signals-sealed-sender/ https://www.ndss-symposium.org/ndss-paper/improving-signals-...

some_furry 2y ago
I should be more precise: Signal's server doesn't know who sent the message, since that information was Sealed. Signal's server does know where to deliver the message to, based on a 96-bit random value generated client-side by the recipient (the delivery token). But it cannot know which user has which delivery token. To understand that, you need to look at the zero-knowledge credentials section of the code. They could randomly drop messages sent to a specific targeted user's delivery token and block messages sent to that targeted user, but they have no way of knowing which user they're targeting. (Also, the client could just enroll a new one if this ever happened and Signal was somehow court-ordered to block delivery to a specific delivery token.)
- grayhatter 2y ago
  Is signal not able to tag and reduce the sealed envelope to a "final" destination network address? I.e. is a sender able to prove that it's impossible for signal servers to do this?
  - some_furry 2y ago
    I don't understand your question. See https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ and https://eprint.iacr.org/2019/1416 https://eprint.iacr.org/2019/1416 if you'd like descriptions for the protocols I'm trying to describe in HN comments.