HN user
government actor can intercept the text message Signal and others use for verification and set up the victims account on a new device
Yes, but if they only control the phone number, you they will register a new account (different cryptographic keys) for you, which is why everyone previously chatting with you will get that "Your Safety Number with Bob changed" message.
Revocation of trust is always a tricky issue, you can look at TLS certificates to see what a can of worms that is.
The Signal server does not forward messages to your devices, and the list of devices someone has (including your own) can and has to be queried to communicate with them, since each device will establish unique keys signed by that IK, so it isn't as bad as having invisible devices that you'd never aware of. That of course relies on you being able to ensure the server is honest, and consistent, but this is already work in progress they are doing.
I think most of the issue here doesn't lie in the protocol design but in (1) how you "detect" the failure scenarios (like here, if your phone is informed a new device was added, without you pressing the Link button, you can assume something's phishy), (2) how do you properly warn people when something bad happens and (3) how do you inform users such that you both have a similar mental model. You also have to achieve these things without overwhelming them.
About the paper: if someone has gotten access to your identity (private) key, you are compromised, either with their attack (adding a linked device) or just getting MitM'ed and all messages decrypted. The attacker won.
The attack presented by Google is just classical phishing. In this case, if linked devices are disabled or don't exist, sure, you're safe. But if the underlying attack has a different premise (for example, "You need to update to this Signal apk here"), it could still work.
latest and shittiest marketing lingo
It exists since Android 6: https://developer.android.com/reference/com/google/android/m...
Informative banner that does not require user interaction to dismiss.
I don't think they are insane, they are quite useful when designing security mechanisms, while at the same time being utter noise for the end-user benefiting from that system.
If you're building a chip to generate prime numbers I do surely hope you know how to select randomness or make constant time & branch free algorithms, just like an engineer designing elevators better know what should be the tensile strength of the cable it'll use. In either cases, it's mumbo jumbo for me, and I just need to get on with my day.
Part of what muddies the water is our collective inability to separate the two contexts, or empower tech communicators to do it. If we keep making new tech akin to esoteric magic, no one will board the elevator.
You will always have to root your trust in something, assuming you cannot control the entire pipeline from the sand that becomes the CPU silicone, through the OS and all the way to how packets are forwarded from you to the person on the other end.
This makes that entire goal moot; eliminating trust thus seems impossible, you're just shifting around the things you're willing to trust, or hide them behind an abstraction.
I think what will become more important is to have enough mechanisms to be able to categorically prove if an entity you trust to a certain extent is acting maliciously, and hold them accountable. If economic incentives are not enough to trust a "big guy", what remains is to give all the "little guys" a good enough loudspeaker to point distrust.
A few examples: - certificate transparency logs so your traffic is not MitM'ed - reproducible builds so the binary you get matches the public open source code you expect it does (regardless of its quality) - key transparency, so when you chat with someone on WhatsApp/Signal/iMessage you actually get the public keys you expect and not the NSA's
Probably not, in any normal case a secondary device shouldn't have that kind of authority to dictate.
It is more concerning if the toggle is on by default and then you carelessly press next (on this or some other kind of phish).
Would probably lead to notification fatigue.
Showing a big snackbar when a new device is added is probably enough, especially if the app can detect there was no "action" on your phone that triggered it.
Key transparency, once rolled out, would help to ensure there is no lingering "bad" device around, but phishing will always be a problem.
Unrelated most likely, signal.me is a legitimate domain used by Signal. Doubt twitter is so on top of Threat Analysis when they fumbled their own redirects from twitter.com to x.com for a while.
Signal doesn't collect that data, but you have no reason to trust me on it.
Look at what data they can provide to governments when compelled by law: https://signal.org/bigbrother/
you also send them your contacts in plaintext so you can find who's also on WhatsApp; signal doesn't
Unrelated most likely, signal.me is a legitimate domain used by Signal. Doubt twitter is so on top of Threat Analysis when they fumbled their own redirects from twitter.com to x.com for a while.
I would also read it from another perspective. Attackers, especially at the level of nation states, will always try to get as many avenues for achieving their goals as possible.
If you have compromised a service, it would be in your interest to make it more popular (assuming you think you are the only one in possession of it).
If you cannot, you don't give up; you just go back to the drawing board (https://xkcd.com/538/). Maybe I don't need to break Signal if I can just rely on phishing or scare tactics to get what I want.
Your phone (primary device) and the linked ones have to share the IK since that is the "root of trust" for you account: with that you generate new device keys, renew them and so on.
Those keys are backed by Keystore on Android, and some similar system on Windows/Linux, i'd assume the same for MacOS/iOS (but I don't know the details) so it's not as simple as just having access to your laptop, they'd need at least root.
Phishing is always tricky, probably impossible to counter sadly - each one of us would be susceptible at the wrong moment.
That's not what the attack does tho - they have access to your private key so they can complete the linking protocol without your phone and add as many devices as they want (up to the allowed limit). If you add a bad device, you are screwed from that moment on, assuming you don't sync your chat history.
You can always see how many devices a user has: they have a unique integer id so if I wanna send you a message, I generate a new encrypted version for each device. If the UI does not show your devices properly than that is an oversight for sure, but I don't think it's the case anymore.
Either way, you'd have to trust that the Signal server is honest and tells you about all your devices. To avoid that, you need proofs that every Signal user has the save view on your account (keys), which is why key transparency is such an important feature.
The attack in that paper assumes you have compromised the user's long term private identity key (IK) which is used to derive all the other keys in the signal protocol.
Outside of lab settings, the only way to do that is: - (1) you get root access to the user's device - (2) you compromise a recent chat backup
The campaign Google found is akin to phishing, so not as problematic on a technical level. How do you warn someone they might be doing something dangerous in an entire can of worms in Usable Security... but it's gonna become even more relevant for Signal once adding a new linked device will also copy your message history (and last 45 days of attachments).