
Technology preview: Sealed sender for Signal - rayvy
https://signal.org/blog/sealed-sender/
======
tptacek
Two observations:

1\. You should look into what other messengers do with sender/receiver pairs
information. One very popular competing messenger logs pairs permanently,
serverside, in order to make UI features work.

2\. One of the least popular attributes of Signal (on Hacker News, at least)
is its lack of federation and ability to interoperate with third-party
clients. This feature is a pretty crystalline example of the kind of protocol
change you can make when you control all the mainstream clients, and that
would be an absolute nightmare for a protocol where you didn't.

~~~
upofadown
Yes you can do stuff more easily if you control all parts of the network. That
doesn't mean we have to give up on standards based messaging just because it
is harder. In the long run silo based systems are more work because you have
to reinvent everything every time you create the next entirely incompatible
system. If that system doesn't catch on then you have to reinvent everything
again and again until you get lucky.

This feature is an example of what happens when you don't solve the meta data
properly in the first place. It doesn't really work that well but unless
Signal starts routing through something like Tor (a system they don't and
can't control) they are stuck with half measures.

~~~
tptacek
The Signal team essentially invented the cryptographic constructions the
current wave of (good) secure messengers are based on, work for which they
were awarded the Levchin Prize at RWC (for perspective, this year's winner was
Hugo Krawczyk). They did the work, then published it, for the other messaging
systems to adopt --- which is why you can easily get a comparable, though
inferior, version of Signal's cryptography in a messenger that doesn't require
phone numbers.

At some point in the future maybe the roles will reverse there, and
interoperability will be a bigger issue. For now, I think Signal's userbase is
benefiting from the decision. If it became necessary, presumably they can
alter their stance in the future.

~~~
joecool1029
> which is why you can easily get a comparable, though inferior, version of
> Signal's cryptography in a messenger that doesn't require phone numbers.

How so? Are things like OMEMO different cryptographically from Signal
protocol?

~~~
agnokapathetic
OMEMO just implements the Double Ratchet Algorithm that Perin and Marlinspike
created for Signal as an XMPP extension.

[1] [https://en.wikipedia.org/wiki/OMEMO](https://en.wikipedia.org/wiki/OMEMO)

[2]
[https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm](https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm)

------
amaccuish
Here's an idea, Signal, how about removing the requirement that everything be
tied to phone numbers?

BBM back in the day worked great with their unique "PINs", that could be
shared by QR code, and I could reject an "add" request.

~~~
tptacek
This is the "Go y u no generics" of secure messaging.

The answer is always the same:

Phone numbers bootstrap a workable social network for ordinary users. Signal's
goal is to transform _all ordinary messaging_ into secure messaging. Not elite
secure messaging. _All messaging_. The most popular messaging application in
the world uses phone numbers for identifiers (as, obviously, does SMS). That's
the goal they've set for themselves.

The simple answer for a lot of questions about Signal is that they aren't
trying to solve every problem, or even many of HN's problems.

If phone numbers are super-problematic for you, use Wire. Consider carefully
the privacy tradeoff you'll be making, though.

~~~
mintplant
I see you explaining and re-explaining the same point throughout this thread:
"ordinary users" are used to using phone numbers as identifiers in the
messaging apps Signal is trying to replace. That's an answer to the question:
why does Signal default to a phone number-based social graph?

What it doesn't answer is: why can't Signal _also_ provide an option to add a
contact using something other than a phone number? Bold, italics, and double-
underline on the _also_. Is it simply a question of finite developer time?

I have multiple specific segments of the population in mind who would benefit
greatly from the secure private messaging Signal provides but for whom
exchanging phone numbers is a total non-starter. "Ordinary", non-technical,
non-"elite secure" people. I hate the framing of this problem as some sort of
niche techie elitism. That's a dodge that reflects a social blind spot of its
own.

~~~
tptacek
I don't understand the complexity or see the blind spot. Your use case is not
a priority for them right now.

~~~
mintplant
I'll re-rephrase. Is it a problem of:

(1) allocating developer time and organizational priorities; or,

(2) a technical incompatibility with Signal's existing, phone number-based
model?

Based on your response I'm inferring (1), but I'm frustrated that this is
never directly answered when the topic comes up.

~~~
tptacek
It's more (1) than (2), is what I think, although I think non-phone
authentication is probably trickier than we think it is and so the two
categories bleed a bit.

I seriously don't understand what people expect in these discussions, though.
The situation is straightforward. A _small_ but vocal minority of Signal's
user base wants non-phone-number identification. Signal hasn't prioritized
that feature. Put up, or use a different messenger. How is this complicated?

Don't pick _horrible_ messengers, like ones where encryption isn't enabled by
default, or doesn't even exist for group messages, or isn't built on a
protocol anyone understands or has reviewed. But even with that constraint,
you have options.

~~~
jake_the_third
> A small but vocal minority of Signal's user base wants non-phone-number
> identification.

Have you done a survey before arriving to this conclusion. If so, I'd love to
take a look at it, if possible. Otherwise, I can't see how you can make this
assertion; everything can be dismissed as a "small but vocal minority".

As a previous signal user, I stopped using signal because I discovered this
issue.

~~~
tptacek
As a previous user of a program that uses phone numbers as identification you
stopped using Signal because you discovered that it uses phone numbers as
identification?

~~~
jake_the_third
Yes. More precisely, I stopped when I discovered that I couldn't decouple the
signal user from my phone number.

More importantly, I'm still very interested in seeing the data behind your
vocal-minority assertion.

~~~
pvg
The survey data you are looking for is WhatsApp.

~~~
jake_the_third
I don't see how. Could you explain?

~~~
pvg
The biggest messaging platform on the planet uses phone numbers as user ids.
It seems very unlikely a _majority_ of users see this as a showstopper.

~~~
jake_the_third
Those users do not use it a secure messaging platform. The see it as a way to
get around SMS fees. The majority of Signal users are likely privacy- and
security-focused, and chose to use signal because of the features it provides
on those fronts.

Comparing those two userbases doesn't make much sense to me.

~~~
pvg
_The majority of Signal users_

I think it's really you who is making the extraordinary claim here and you
should be providing the evidence. Signal's goal, as has been repeated many
times in these threads is to replace SMS and other less-secure forms of
messaging for as many users as possible, not to cater to somewhat off-the-
beaten-path concerns over phone numbers. They are aiming for _users of
messaging_. And they are making the very reasonable inference that most of
those users are not hung up on identifying themselves with a phone number.

Additionally, if Signal's current users cared about the phone number thing
_that_ much, they wouldn't be using Signal to begin with. Where's your survey
data that says Signal users just can't stand the phone-number-as-id thing?

~~~
jake_the_third
I agree that my claim was unsubstantiated and redact it.

What I was trying to convey is that I would expect people who don't understand
or care enough about their personal privacy would use more popular and
mainstream messengers. Whether people who care about privacy consider phone
numbers private or not is something we need data to determine.

> Where's your survey data that says Signal users just can't stand the phone-
> number-as-id thing?

That's exactly what I'm asking for. At this point, we're _both_ speculating.
None of us can make solid claims about either userbase without providing
evidence. tptacek most certainly can't claim " a small but vocal minority of
Signal's user base wants non-phone-number identification" without providing
evidence either, which is the original objection that started this thread.

Don't expect people to take your reason for dismissing their concerns
seriously when you base it on your personal perception or beliefs in stead of
facts, and don't make unsubstantiated claims to discredit their concerns.

------
esotericn
I'm confused here. It seems the identities are trivially linkable via the IP
address.

The Signal servers can't determine cryptographically that the message
originates from Device A. But it is certainly from device A, because this
isn't a peer to peer protocol.

It seems to me like what you'd need to make this work is some sort of
intermediate layer, a bit like onion routing, that would have messages arrive
at the Signal servers without basically giving everything away in the source
IP field.

With general use of NAT there's a N-to-one mapping of identities to IP
addresses, sure, but this seems to be technically true whilst in many cases
completely erasing any benefit of this entirely.

~~~
ric2b
I think the point is that they can simply discard IP addresses as soon as they
receive the message.

If later they get a request from the NSA to look at their database, the
undelivered messages can no longer be traced back to the sender.

~~~
esotericn
Aha! I see now. So it's a temporal thing.

Previously, an undelivered message would have to sit on Signal's servers with
the sender's metadata in cleartext. Now, it doesn't.

------
geofft
I'm not sure I understand the feature. It protects the sender's identity _from
their servers_ , or _from the recipient_? What's the use case / threat model?

I think it prevents their servers from correlating my identity and my IP
address etc., but since I want replies and I'm asking the server about
replies, doesn't that operation tell the server what my identity is anyway?

(There are some comments here talking about anonymous messages, but that
doesn't sound right since the phone number is apparently kept in the
encrypted, inner envelope, and also how would you route replies if you didn't
have an identity of some sort for the sender?)

~~~
tptacek
It prevents their servers from easily tracking (and, importantly, logging) who
sent which messages to whom.

~~~
geofft
Oh, I see - it effectively hides the fact that a _conversation_ occurred
between two participants from their servers. They know that I'm at my IP, they
know that you're at your IP, and they know that we're both sending messages,
but this feature prevents them from knowing whether we're sending messages to
each other.

~~~
Spivak
It seems like this is backwards: you have an address and username, they have
an address and username. They see the source address and destination username.

So suppose an attacker sees two packets:

Encrypted("Indian for dinner?"): Their username, your address.

Encrypted("Sure, sounds good."): Your username, their address.

From this they could be reasonably sure you two are talking but it's less data
than they had before and now that attacker needs to either know you're using
the source address or see both messages to get the full picture.

~~~
tialaramex
What do you mean here by "address" ? And indeed "username" ?

Suppose Alice is asking about Indian and Bob replies that it sounds good.

A passive attacker sees TCP/IP packets between Alice's IP address and Signal's
and between Bob's IP address and Signal's. They get no other information from
this beyond that Alice and Bob use Signal (and perhaps not even that if Signal
shares IP addresses with other services)

The Sealed Sender feature makes no difference in that layer

If an attacker has control of Signal's servers (or perhaps Signal's server
admins are secretly bad guys) ordinarily they would be able to see the sender
and recipient of every message.

With Sealed Sender, the servers don't know the Sender any more, only that the
Sender seems to be someone permitted to send messages to this recipient.

You could try to correlate IP addresses to Signal users, but you have
absolutely no guarantee that they're correlated, much less that there's a nice
1:1 correspondence.

In a mundane example, Alice proposes Indian food then leaves her office, her
phone disconnects from WiFi and goes to a 3G network. The reply from Bob is
picked up by Alice using a completely different IP address, because she isn't
in the office any more.

------
StudentStuff
This is an unexpected move, perhaps Briar, Matrix and other distributed
platforms are putting more pressure on Signal to show forward progress on the
serious metadata issue with Signal and most other centralized platforms?

Its been a rallying cry/common complaint by those who are technically inclined
and privacy conscious for years now, surprised OWS would choose to give credit
to the problem.

~~~
tptacek
No mainstream messenger has ever done a better job with metadata than Signal.
It took Signal several years after launch just to get user profiles with names
and stuff, purely because of privacy concerns. Read the blog post they wrote
about GIF sharing to get a sense of how seriously they take this, then compare
how their features work to other mainstream messengers.

There is one privacy issue people put pressure on Signal about, and that's the
use of phone numbers. Apart from that, Signal has always led the field on
privacy issues.

~~~
StudentStuff
Briar is leading the field on privacy issues today, unlike Signal. There is no
metadata leaking who you are sending messages to or from, just a connection to
the Tor Network. This problem is still unsolved in Signal, with only partial
protection of some messages looking to be added in the future, while
mitigation tactics like running your own server are unsupported & discouraged
by Open Whisper Systems.

The post about Giphy integration was a great piece of writing about an
interesting technical challenge, and Signal's solution to the problem (a TLS
proxy run by them, with a client that only accepts Giphy's TLS certificate,
making queries quasi-anonymous) is not a bad way to go about solving things.

~~~
tptacek
I am willing to stipulate "short of running everything over Tor" for the sake
of argument.

~~~
StudentStuff
I'm not looking to argue with you, just pointing out the current state of
affairs wrt why so many privacy minded, tech aware folks either won't use
Signal or choose to move conversations off it as quickly as possible.

The reasons for avoiding Signal (metadata leakage, mandatory phone number
usage, questionable 3rd party dependencies, etc) are valid, despite how I
often argue to the contrary in favor of getting as many people on Signal as
possible and using it for daily communication. Talking common sense to this
demographic is hard though, in the context of basic security concerns
persisting year after year.

On the flipside, the phone number as identifier issue has caused apps like Kik
(super popular among the gay community, despite shit security), Wickr and Wire
to become popular among the non-tech demographics, which is extremely
disheartening.

~~~
tptacek
Of those issues, I believe only mandatory phone numbers are valid, for what
it's worth. And I'm fine with mandatory phone numbers; there are other options
for people who have a problem with that.

~~~
StudentStuff
You obviously have a different opinion on what a standard threat model is
then...

~~~
trash_panda
There is no such thing as a "standard threat model". That's why the threat
modeling concept exists in the first place, so you can adapt different
solution to different requirements.

It is totally OK if you are extremely worried about hypothetical scenarios
where the phone number you used to register to the Signal network can be
correlated to your physical location and then a gas station camera filmed you
and then all is lost; but I want to believe that really at risk people are
smarter than that, and just get a burner phone and even pay a homeless person
a few bucks to buy it for them.

There are also ways to get a phone number through the Internet, so you don't
even have to go to a physical location to buy it.

I think that's why Signal isn't prioritizing this right now, phone numbers can
be a problem? yes. Is it hard to get a fake phone number that is not traceable
to you? not really. Next problem please.

I think Signal is achieving the goal of being the default go-to secure
messenger. I'm sure, even technical people who like to nerd out on
alternatives, faced with a real world risky situation when they have to
communicate with a non-technical person, would recommend Signal without a
second thought.

------
ngngngng
How does signal do media messages? All the time i'll open signal and see
someone sent a picture but I have to download it. If signal doesn't store
anything on it's own servers but ip and timestamp, where is this media message
stored after it's sent but before I received? Am I just downloading it from
the device that sent it to me? That would explain why it's so unreliable.

~~~
windexh8er
"Unreliable" \- It's not. I've been using it since the early RedPhone and
TextSecure days. The only times it's been remotely unreliable is because of my
connectivity. I can say I've never had either a lost picture or file sent to
me that I can recall. My family and circle of friends (~40 people) use it
daily. I just transferred my backup from my old phone to a new one (which by
the way thank you for implementing real backups Signal devs!) and I was
surprised that my backup sat at over 300 thousand messages. I do leverage many
group chats that are repositories of pictures, but I was actually surprised at
the volume.

To say Signal is "unreliable" is bull shi*. It's a fantastic product and
service that I would gladly pay for but am glad it's free. In the meantime
I'll continue to donate as Signal has been very reliable in my years of use.

~~~
akvadrako
Sorry but you must see how that's obviously jumping to conclusions. Just
because you haven't had issues with Signal doesn't mean it's reliable.

I have been using it for 3 years and struggle to recommend it to people
because I constantly have reliability issues, including messages delayed for
hours, bugs where contacts get in an unusable state and other little weird
things.

Whatsapp doesn't have these issues, so even if it's due to not being online
100% of the time, Signal should deal with it.

~~~
windexh8er
I'm not jumping to conclusions. For a product to have millions of users and no
long term, outstanding, unfixed issues in their repo I don't seem to see the
validity in your claim. Claiming it's Signal because your WhatsApp works is,
obviously, jumping to conclusions.

Can you provide any issue you've submitted from years ago that hasn't been
addressed? Please post it, I'd like to see.

~~~
pwnna
Uh... about the long term unfixed issues.. They don't have them in their repo
because they just close the ones that are open too long:
[https://github.com/signalapp/Signal-
Android/issues/7598](https://github.com/signalapp/Signal-Android/issues/7598)

Granted, a lot of these are probably outdated. However, given that there are
literally >1000 issues closed by a bot, there must be some that are still
valid but no one actually looked at it.

------
Paul-ish
Without cover traffic, its not clear to me that this would prevent a
correlation attack from an adversary with resources.

~~~
kijiki
"These protocol changes are an incremental step, and we are continuing to work
on improvements to Signal’s metadata resistance. In particular, additional
resistance to traffic correlation via timing attacks and IP addresses are
areas of ongoing development."

It won't prevent correlation attacks, but it does make metadata attacks in
general harder and less confident. An improvement is an improvement even if it
doesn't completely solve a problem.

------
faitswulff
You can test out the sealed sender feature on the beta releases of Signal:
[https://support.signal.org/hc/en-
us/articles/360007318471-Ho...](https://support.signal.org/hc/en-
us/articles/360007318471-How-do-I-join-Signal-s-beta-)

------
tmin
How to fight spam if sender identity is not known? Currently I get at least a
few marketing calls a week and don't know how to make them stop other than
blocking the numbers.

~~~
wskinner
From the Signal blog post:

> To prevent abuse, clients derive a 96-bit delivery token from their profile
> key and register it with the service. The service requires clients to prove
> knowledge of the delivery token for a user in order to transmit “sealed
> sender” messages to that user.

~~~
forapurpose
They add:

> Additionally, blocking a user who has access to a profile key will trigger a
> profile key rotation.

People who don't know you can't use the new sender privacy beta feature, but
if you are willing to risk spam then you can allow everyone to use it:

> users who want to live on the edge can enable an optional setting that
> allows them to receive incoming “sealed sender” messages from non-contacts
> and people with whom they haven’t shared their profile or delivery token.
> This comes at the increased risk of abuse, but allows for every incoming
> message to be sent with “sealed sender,” without requiring any normal
> message traffic to first discover a profile key.

------
akhilramolla
TO signal, Verify my identity, send me an OTP.

------
Confiks
Can the URL be changed to the Signal blog post at
[https://signal.org/blog/sealed-sender](https://signal.org/blog/sealed-
sender)?

~~~
dannyw
Yes, I don’t understand why TechCrunch blogspam is exempt from the normal
original source rules. They don’t add any value and reduce the amount of
information.

~~~
pvg
_is exempt from the normal original source rules._

It's not. But if you want something fixed/looked into, your best bet is
emailing the admins. They're super-responsive.

