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

131–140 of 178 posts

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

#131

Post by Sir_Cmpwn »

tptacek wrote: post #126
Sir_Cmpwn wrote: post #96

Earlier quoted context omitted.

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 sce…

I think you're misinterpreting my arguments because it suits your preconceptions if that were the case. GCM is not just client code. I clarified when someone said the client could be replaced.

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

#132

Post by tptacek »

Sir_Cmpwn wrote: post #131
tptacek wrote: post #126

Earlier quoted context omitted.

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 sce…

I think you're misinterpreting my arguments because it suits your preconceptions if that were the case. GCM is not just client code. I clarified when someone said the client could be replaced.

Same issue, and here's Moxie himself on it:

https://news.ycombinator.com/item?id=13054940#13056554

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

#133

Post by vertex-four »

x0x0 wrote: post #129
vertex-four wrote: post #121

Earlier quoted context omitted.

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

There's a reason web browsers just don't allow users to easily get past the annoying pages when there is a chance they're being attacked. I see no reason that Matrix clients would be required to allow users to break security without having a persistent banner saying "this room is insecure".

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

#134

Post by Borating »

x0x0 wrote: post #125
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/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.

If Signal was federated anyone could write a signal client to openBSD or Alpine Linux.

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

#135

Post by Sir_Cmpwn »

tptacek wrote: post #132
Sir_Cmpwn wrote: post #131

Earlier quoted context omitted.

I think you're misinterpreting my arguments because it suits your preconceptions if that were the case. GCM is not just client code. I clarified when someone said the client could be replaced.

Same issue, and here's Moxie himself on it: https://news.ycombinator.com/item?id=13054940#13056554

I have read this; I don't generally comment on issues I'm not informed on.

Moxie is simply wrong on many of these points, and has been for a while and has had this repeatedly pointed out with no change in opinion. I would rehash this here but you'd be better off simply reading the linked thread and looking at other rebuttals. In particular I remember a 500+ comment GitHub thread on the Play Services issue where Moxie was repeatedly dismissive and rude to those who take issue with the glaring security problems in Signal.

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

#136

Post by rahrahrah »

sliken wrote: post #111
dublinben wrote: post #35

Earlier quoted context omitted.

None of the email headers are protected in any way for a PGP-encrypted email. All the same metadata is that collected from plaintext email is still available on "encrypted" email. You literally can only protect the body of the email. In surveillance, that is often the least interesting or valuable piece of information.

As mentioned signal doesn't hide contact discovery. But it does a pretty good job of hiding who you are chatting to from everyone but OWS. OWS received a Grand jury subpoena and was only able to produce "the only information we can produce in response to a request like this is the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service.". Certainly a NSL might comp…

> OWS received a Grand jury subpoena ( ... )

Link please

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

#137

Post by ajamesm »

haffenloher wrote: post #103
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.

This is a common misconception: NSLs are a legal tool that can be used to extract certain types of information (such as subscriber information and maybe a little bit of transactional information) that a service provider already has stored on their servers [0]. However, they cannot be used to force a service provider to write and deploy code. [0] NSLs are not magic - https://www.youtube.com/watch?v=YN_qVqgRlx4&t=20m16…

I was wondering about the extent of NSLs in that regard. Thanks for clarifying.

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

#138

Post by ajamesm »

MichaelGG wrote: post #130
sliken wrote: post #94

Earlier quoted context omitted.

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?

Can I just chime in again and say, if your threat model includes an adversary who could compromise the Google Play Store deployment process, then you should be comfortable with validating the SHA hash on your APK binaries.

Android is pretty open about letting you sideload and run binaries, which you can do easily as a non-rooted end user. You can personally GitHub pull & compile the Signal app and you're good to go (w/r/t compromised software download).

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

#139

Post by haffenloher »

sliken wrote: post #111
dublinben wrote: post #35

Earlier quoted context omitted.

None of the email headers are protected in any way for a PGP-encrypted email. All the same metadata is that collected from plaintext email is still available on "encrypted" email. You literally can only protect the body of the email. In surveillance, that is often the least interesting or valuable piece of information.

As mentioned signal doesn't hide contact discovery. But it does a pretty good job of hiding who you are chatting to from everyone but OWS. OWS received a Grand jury subpoena and was only able to produce "the only information we can produce in response to a request like this is the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service.". Certainly a NSL might comp…

> Certainly a NSL might compel OWS to add additional logging

NSLs cannot be used for that. They're a legal tool that can be used to extract certain types of information (such as subscriber information and maybe a little bit of transactional information) that a service provider already has stored on their servers [0]. However, they cannot be used to force a service provider to write and deploy code.

[0] NSLs are not magic - https://www.youtube.com/watch?v=YN_qVqgRlx4&t=20m16s

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

#140

Post by tptacek »

Sir_Cmpwn wrote: post #135
tptacek wrote: post #132

Earlier quoted context omitted.

Same issue, and here's Moxie himself on it: https://news.ycombinator.com/item?id=13054940#13056554

I have read this; I don't generally comment on issues I'm not informed on. Moxie is simply wrong on many of these points, and has been for a while and has had this repeatedly pointed out with no change in opinion. I would rehash this here but you'd be better off simply reading the linked thread and looking at other rebuttals. In particular I remember a 500+ comment GitHub thread on the Play Services issue where Moxie…

"The glaring security problems in Signal"?
Post reply on HN