Live data from Hacker News

Valid Signal privacy issues shrugged off while patches quietly rolled out

403forbiddenblog.blogspot.com

41–50 of 53 posts

Re: Valid Signal privacy issues shrugged off while patches quietly rolled out

#41
post #9
post #5

I was expecting to hear about someone who got a new phone, set up Signal using the phone number, and then communicated with contacts without any more authentication. This doesn't appear to be anything of the kind. Signal has implemented a migration system so that people can move to a new phone without changing the safety number. Then a bunch of references to the promises Signal makes about re-verifying if the safety…

I imagine there is a human factors tradeoff here. If signal notified on each migration, users with even medium sized contact lists would likely be getting constant notifications - making the alert useless. See medical device or aviaton alerts experiences.

Not in this case. If the long term identity is transferred from device to device there is no extra risk to trade off.

It is like copying your PGP private keys from one device to another. The associated public keys are still in your correspondents key stores, certified or not. Nothing changes for them and there is no reason for them to know what you have done.

There is nothing here for Signal to do. Their issue is is the one that everyone who creates an encrypted E2EE messenger faces. There is no good analogy for cryptographic identities. So it is hard to produce a good conceptual model that the user can use to understand what they should expect and how they should react.

Re: Valid Signal privacy issues shrugged off while patches quietly rolled out

#42

Related question… How can an app developer guarantee end to end encryption when the main entry point is almost always a virtual keyboard? Seems like the weakest part of the chain.

No one can guarantee any thing. Not even most gods or a time traveler from 1000 years in the future. An omnipotent being could.

It makes sense to attack and work on problems that are actually happening and are solvable within some level of aspiration.

I’m not sure how things work on either mobile OS. Perhaps there can be more clear language and notifications on if everything is being passed to the virtual keyboard developer or not.

Unless you mean Apple, Google, and other Android manufacturers themselves. That’s beyond the scope of any E2E stuff.

Re: Valid Signal privacy issues shrugged off while patches quietly rolled out

#43
post #36
post #7

Earlier quoted context omitted.

The "safety number" also encodes both participants phone numbers (the verifier and the person to be verified). So you would be a little foolish to publish it in say, a blog post if you weren't intending those phone numbers to be public information. I'm also very amused that the author censored part of the QR code, but not the human readable text below it containing the exact same data.

> The "safety number" also encodes both participants' phone numbers Um, not that I know of. A quick check, though, the QR code is a bunch of binary data, so I dove into the source code: https://github.com/signalapp/libsignal-client/blob/4446b648f... > very amused that the author censored part of the QR code, but not the human readable text below it containing the exact same data So what is it now, does it contain the…

If I remember correctly the safety number is a concatenation of hashes of both peers’ id (phone number) and public key. So while it doesn’t leak your phone number, you can probably bruteforce the phone number if you know the pubkey. But you also probably can’t get the pubkey without knowing the phone number so…

Re: Valid Signal privacy issues shrugged off while patches quietly rolled out

#45
post #27

Earlier quoted context omitted.

All security ultimately reduces to physical security. If you can’t secure your physical phone, all digital security is moot.

I would say "requires" rather than "reduces to". Just like all security requires vetting personnel. There are just a lot of checkboxes that need to be ticked as table stakes in the security game.

I would state that physical security is both necessary and sufficient to protect information.

Vetting personnel isn’t necessary, nor is it sufficient, to protect information.

Protecting more than just the information, is a different argument.

If we’re talking about securing personal information that has a physical footprint of a cell phone, vetting personnel is irrelevant. Never let your phone leave your person, on pain of death, so to speak.

If we’re talking about securing a building, vetting personnel is just an extension of physical security, anyways.

All of those checkboxes will ultimately reduce to being an extension of physical security.

Re: Valid Signal privacy issues shrugged off while patches quietly rolled out

#46

Related question… How can an app developer guarantee end to end encryption when the main entry point is almost always a virtual keyboard? Seems like the weakest part of the chain.

How can they guarantee end-to-end encryption when someone could be looking over your shoulder as you type your message? Same answer. They don’t control the input, they just keep it safe once it’s in transit.

Yeah, fair point and largely the point of the article. Too many conditions exist for Signal to accidentally reveal information. I still wonder how many people assume the privacy offered is much more than just the data in transit. I’d bet a large percentage of users believe that.

Re: Valid Signal privacy issues shrugged off while patches quietly rolled out

#47
I guess if you devote a lot of energy to researching a vulnerability and the developers explain to you that it's not actually a vulnerability, you only have two choices:

- Accept that you misunderstood and have mostly wasted your time by pursuing unnecessary research. Refocus on new vuln research.

- Become indignant and accuse the developers of being uncooperative and conspiratorial by refusing to validate your research. Double down on publicizing your original research.

Which response is correct hinges on whether the developers are justified in denying the vulnerability. As a reader, I was prepared to have the second response but after reading the article I feel the first - this was a waste of everyone's time.

Re: Valid Signal privacy issues shrugged off while patches quietly rolled out

#48

Earlier quoted context omitted.

No, you're absolutely right. The author complains that with physical possession of the device that it's possible to transfer Signal's private key material to a new device, leaving the old safety number intact. The author apparently expects the safety number to change in order to alert the person on the other end that there "might be a hostage situation," evidently not realizing that the attacker could just, well, use…

No, the author is right. There are many cases where an attacker can access a device for a short time and/or without the owner realizing that the phone was tampered with.

Sure, but exactly how would you build something that's robust against that kind of access?

If you leave cryptographic keys lying around unprotected they should be assumed to be compromised.

Re: Valid Signal privacy issues shrugged off while patches quietly rolled out

#49
post #35
post #11

Am I misreading this, or is this the Signal version of the bug bounty classic "user impersonation vulnerability: if I steal this session token, I can impersonate the user who it belongs to"?

no session tokens involved here; we talk about the crypto behind device-to-device transfer in this blog post ( https://signal.org/blog/ios-device-transfer/ ) and the concepts and UX research surrounding Safety Numbers (what they are, how they're represented, and how we found they bring the most utility to the platform) in these 2016 & 2017 blog posts: https://signal.org/blog/safety-number-updates/ https://signal.org/…

Yes, but it's the same general idea of obtaining private keys. I agree that this isn't much of a vulnerability.

Re: Valid Signal privacy issues shrugged off while patches quietly rolled out

#50

Earlier quoted context omitted.

No, the author is right. There are many cases where an attacker can access a device for a short time and/or without the owner realizing that the phone was tampered with.

Sure, but exactly how would you build something that's robust against that kind of access? If you leave cryptographic keys lying around unprotected they should be assumed to be compromised.

Signal has a PIN, too. If that's required for the transfer, then it would prevent this in the case of brief, surreptitious access. A hostage scenario is impossible
Post reply on HN