Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Encrypted messengers: Riot, not Signal, is the future

titus-stahl.de

Post reply on HN
Print view View original

121–130 of 178 posts

Re: Encrypted messengers: Riot, not Signal, is the future

#121

Post by vertex-four »

meredydd wrote: post #78
zimbatm wrote: post #33

Earlier quoted context omitted.

If browsers are able to deprecate old encryption layers I don't see a reason why matrix client wouldn't be able to do the same. And as with browsers, if the clients or servers don't get upgraded then at some point they will stop working.

That is only possible at all because web browsers are an oligopoly. There are only four organisations whose opinions matter, so they can coordinate to make breaking changes. (Even so, SHA1 deprecation is happening 1000x slower than, say, Whatsapp's rollout of E2E encryption.) This level of oligopoly would not be tolerable to those who want to federate Signal-like apps. The whole point is to make it practical to use a…

A reasonable upgrade path is to do "room versioning". Each server would have a maximum supported room version, and publish it to each room they participate in, and every room has a version. When every server in the room agrees on a new version, they can publish a message to update the room version, and start talking over the new protocol. Older servers then can't join the room unless they agree to the room's new protocol.

Clients can then warn when they're in rooms with older versions than the latest supported, and since nobody wants the people they're talking to to receive scary warnings about insecurity, they'll upgrade.

And, of course, we can do similar with client versioning.

Re: Encrypted messengers: Riot, not Signal, is the future

#122

Post by rando444 »

sliken wrote: post #88
widforss wrote: post #71

Earlier quoted context omitted.

> Signal - while certainly can be setup/hosted by anyone else separate of OpenWhisper - leaves some to be desired in the actual self-implementation details; just not enough tutorials out there. That is the problem at hand, that Signal _does_not_federate_. You could modify your Signal app to connect to your own server, but then you would not be able to talk to anybody else. For the record I prefer usability and walled…

I think signal made the right decisions raising the bar for encryption while maintaining extreme ease of use. Random Joe can click on it on the app store and chat with anyone in his addressbook that runs signal within a minute or so, with no expertise whatsoever. However I see no reason why a similar p2p app couldn't manage similar without a central server. Trick is cell phones (at least on WAN) do not accept incomin…

The idea of supernodes is what got everyone paranoid (with reason) that they were now able to be spied upon.

Re: Encrypted messengers: Riot, not Signal, is the future

#123

Post by temprature »

hkt wrote: post #84
Cyph0n wrote: post #15

Earlier quoted context omitted.

With such a system, you must end up trusting a certain entity; it's turtles all the way down otherwise. No system is independently secure. Similar questions include: What if a CA is compromised? What if Apple/MS bundles unwanted certs with the OS? What if Intel/AMD biases the on-die hardware RNG or other hardware crypto primitives? What if Apple/MS bundles a backdoored compiler a la "Reflections on Trusting Trust"? W…

Does Signal support reproducible builds, at least? Real question, I don't know.

https://whispersystems.org/blog/reproducible-android/

Re: Encrypted messengers: Riot, not Signal, is the future

#124

Post by tptacek »

Sir_Cmpwn wrote: post #79
tptacek wrote: post #75

Earlier quoted context omitted.

Your argument has become circular, because the what Signal uses push notifications for isn't security-relevant: the messages are empty and used only as a wakeup.

They still contain information, though. They say when you're talking on Signal. Matched with someone else's messages at about the right frequency to indicate a conversation, they give a pretty decent idea of who you're talking to.

They give the same information that TCP/IP traffic analysis does.

Re: Encrypted messengers: Riot, not Signal, is the future

#125

Post by x0x0 »

Forbo wrote: post #64
ajamesm wrote: post #54

Earlier quoted context omitted.

Sorry, am I missing something? It's my understanding that Signal is ETE encrypted. All an NSL would get you is ciphertext and metadata.

The scenario I'm imagining is that Google and OWS receive NSLs requiring them to push a modified APK that could do nefarious things.

Google/Apple could also receive a NLS ordering them to write and install a keylogger on your specific device in their next OS update. There's really not much you can do about that.

Re: Encrypted messengers: Riot, not Signal, is the future

#126

Post by tptacek »

Sir_Cmpwn wrote: post #96
sliken wrote: post #92

Earlier quoted context omitted.

Why? Google doesn't know who you are chatting with, or even the size of the messages you are sending. Google just sends a "wake up signal and check for messages". That's it.

Keep reading the thread.

Your argument on this thread is incoherent. You begin by suggesting that GCM is problematic because it's a component of a larger platform library that gives Google control of Android phones. When it's pointed out that GCM push can be supported without that platform library, your argument shifts: it's the messages themselves that are dangerous. When it's pointed out to you that the messages are empty, you invent a scenario in which GCM push messages enable a kind of traffic analysis that on-the-wire traffic analysis can't already accomplish.

Were this my argument, rather than pointing me to a thread where my points were continually and reliably refuted, I'd take this opportunity to instead restate my argument clearly.

Re: Encrypted messengers: Riot, not Signal, is the future

#127

Post by BoorishBears »

Cursuviam wrote: post #18
exstudent2 wrote: post #10

A question I've had about Signal is what is stopping Apple from modifying and rebuilding the source with a backdoor in it? Is this technically possible (seems like it would be since they control distribution of the binary to devices)? The article is correct in stating that web based chat is inherently insecure but it seems all iOS apps are also inherently insecure. I'm by no means an expert though so would love to he…

What's to stop them from modifying the OS itself to spy on you? On a closed platform, you don't have peace of mind from spying.

On an open platform, you don't have peace of mind from spying...

Unless every single part of your platform is open and you build it yourself. But then make sure the parts you use to build it aren't tampered with.

I think somewhere along the conclusion of that train of thought you'll need to build a fab to make sure there aren't silicon level backdoors in your hardware.

Re: Encrypted messengers: Riot, not Signal, is the future

#128

Post by BoorishBears »

sliken wrote: post #98
Cursuviam wrote: post #18

Earlier quoted context omitted.

What's to stop them from modifying the OS itself to spy on you? On a closed platform, you don't have peace of mind from spying.

If you care that much, just run your own OS. Many android phones have quite a few options available.

A custom Android OS is the last thing I'd consider secure...

Re: Encrypted messengers: Riot, not Signal, is the future

#129

Post by x0x0 »

vertex-four wrote: post #121
meredydd wrote: post #78

Earlier quoted context omitted.

That is only possible at all because web browsers are an oligopoly. There are only four organisations whose opinions matter, so they can coordinate to make breaking changes. (Even so, SHA1 deprecation is happening 1000x slower than, say, Whatsapp's rollout of E2E encryption.) This level of oligopoly would not be tolerable to those who want to federate Signal-like apps. The whole point is to make it practical to use a…

A reasonable upgrade path is to do "room versioning". Each server would have a maximum supported room version, and publish it to each room they participate in, and every room has a version. When every server in the room agrees on a new version, they can publish a message to update the room version, and start talking over the new protocol. Older servers then can't join the room unless they agree to the room's new prot…

This is remarkably contrary to how people actually use software. What people see is "click this button to make annoying red flashing shit stop so I can do what I want to do".

ala http://i.imgur.com/H0uVqFe.jpg

Re: Encrypted messengers: Riot, not Signal, is the future

#130

Post by MichaelGG »

sliken wrote: post #94
Forbo wrote: post #64

Earlier quoted context omitted.

The scenario I'm imagining is that Google and OWS receive NSLs requiring them to push a modified APK that could do nefarious things.

Google can't push a new Signal APK, it's signed by OWS, not google. 3rd parties can download the signal source and compile it. Not sure if there's enough information available to product a bit identical (and thus verifiable binary). I guess a NSL might compel OWS to push a binary specifically for a targetted user. If that's in your threat model you definitely need to take additional steps.

So Android checks the APK is signed by the same publisher on update? What about for new users? Nothing stops Google from just changing which package is on Play Store, right? Where does signature validation come in, and how would a user tell?
Post reply on HN