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

We can do better than Signal

icyphox.sh

Post reply on HN
Print view View original

281–290 of 290 posts

Re: We can do better than Signal

#281

Post by Caligatio »

skinkestek wrote: post #278
Caligatio wrote: post #277

Earlier quoted context omitted.

I should have stated in my original post that there are a lot of features that Signal could add/improve on; my post was meant to be commentary about the implementation critiques levied against Signal. Your only point I disagree with is backups: there is simply no way for a non-for-profit company that doesn't monetize user data to afford providing cloud backups. P.S. "New" groups in Signal support up to 1,000 users, d…

> Your only point I disagree with is backups: there is simply no way for a non-for-profit company that doesn't monetize user data to afford providing cloud backups. I would actually prefer local backups. I can always upload them to the cloud myself, and then I pay :-) > P.S. "New" groups in Signal support up to 1,000 users, did you need something bigger? OK, this might come off as moving the goal posts, so let me say…

At least on Android, there is a local backup option although you need to manually pull it off the device.

I get what you're saying about chat/moderation tools. For some reason I limit my view of Signal to groups of people I actually know. I would personally never use it instead of something like Gitter or community-based chats. I fully agree various chat programs (mostly) each have their own niche.

Re: We can do better than Signal

#282

Post by ThePhysicist »

dublinben wrote: post #222
ThePhysicist wrote: post #89

I never understood what problem E2E encryption actually solves if you don't have full control over the client. All it would take Signal or WhatsApp to extract all your private messages is a single update of the client, which is trivial to do and currently very hard to validate as e.g. Apple does not even (to my knowledge) provide checksums to end users. The problem of messaging as it is today is that we missed the op…

>what problem E2E encryption actually solves Pervasive, passive surveillance. If your threat model includes individually targeted exploits, then you'll need to look for other solutions.

You don't need E2E encryption for that, transport layer encryption will do just fine in that case.

Re: We can do better than Signal

#283

Post by Caligatio »

names_are_hard wrote: post #250
Caligatio wrote: post #236

Earlier quoted context omitted.

I understand what you're saying but I don't know if calling it vendor lock in is quite correct. You can export your list of messages out of Signal and presumably import them to whenever you motivated to do so. Your friends could then join you on the new service and life would continue on. I am personally unaware of any communication service with a universally portable user identifier and that allows you to freely swi…

Well... yes, email and sms and telephone. They're protocols that anyone can decide to support and participate in. Honestly SMS was a good solution for my needs for 1:1 messages, it just didn't properly evolve to support the f a featureset we expect from modern messaging.

I was actually thinking about this before I posted and discounted email. It has high interoperability but you cannot move your email address to a different provider if you didn't opt to use a domain you owned.

This is obvious when you say it but I can port my phone number between phone companies whereas I cannot move my Gmail address to a different email provider.

Re: We can do better than Signal

#284

Post by Caligatio »

jokoon wrote: post #280
Caligatio wrote: post #29

I feel like Signal is held to a ridiculously high bar when it comes to anything. Is it perfect? No. But come on now; I see other threads on HN where people are debating/bashing their use of Intel SGX, really? Assuming you trust the client builds (or use a verified build) and verify the public key, all of these arguments go out the window with the exception of exposing your phone number. This situation seems like a pr…

If the goal is to protect yourself from the NSA, switching from WhatsApp to signal is not going to change things. Signal could well be a honey pot software designed to attract people who don't want to be listened to by the NSA. I agree that signal is secure and oriented towards privacy, two different things.

I believe you're talking about a hypothetical but are you saying that the E2E crypto in Signal is flawed and therefore useful as a NSA honeypot?

We've seen from previous subpoena that Signal really only does retain the limited data they claimed and the content is auditably correctly encrypted.

Re: We can do better than Signal

#285

Post by bilal4hmed »

Caligatio wrote: post #276
bilal4hmed wrote: post #258

Earlier quoted context omitted.

Well Signal has put itself as a high privacy option, we are open, check out our code. Well we can check the client code but we dont know what you are running on the server. FB, Google etc never claimed to be open source with their infrastructure. So if WhatsApp cant be trusted as to what happens on the server, right now neither can Signal. Can Signal show that what they are running on the server is the same as whats…

You don't need to trust the server with E2E encryption. If you can review and trust the client, the server only has access to the information that the client sends. Even if they release up-to-date server code, we have no way to confirm that's the code that's running on their servers. People would then complain that they don't have shell access to the servers to ensure the code is what is expected.

Well one way you could confirm is to run your own instance of the server and run the client against it and the client works as if you are going against Moxie's server

Right now if you run the published server code and point the client certain features don't work. Doesn't that sound a little concerning ?

Re: We can do better than Signal

#286

Post by growse »

ThePhysicist wrote: post #282
dublinben wrote: post #222

Earlier quoted context omitted.

>what problem E2E encryption actually solves Pervasive, passive surveillance. If your threat model includes individually targeted exploits, then you'll need to look for other solutions.

You don't need E2E encryption for that, transport layer encryption will do just fine in that case.

The transport between where and where?

Re: We can do better than Signal

#287

Post by Evidlo »

Caligatio wrote: post #283
names_are_hard wrote: post #250

Earlier quoted context omitted.

Well... yes, email and sms and telephone. They're protocols that anyone can decide to support and participate in. Honestly SMS was a good solution for my needs for 1:1 messages, it just didn't properly evolve to support the f a featureset we expect from modern messaging.

I was actually thinking about this before I posted and discounted email. It has high interoperability but you cannot move your email address to a different provider if you didn't opt to use a domain you owned. This is obvious when you say it but I can port my phone number between phone companies whereas I cannot move my Gmail address to a different email provider.

You can see some proposals for server migration/fallback here:

https://github.com/matrix-org/matrix-doc/issues/915

Re: We can do better than Signal

#288

Post by vbezhenar »

Caligatio wrote: post #276
bilal4hmed wrote: post #258

Earlier quoted context omitted.

Well Signal has put itself as a high privacy option, we are open, check out our code. Well we can check the client code but we dont know what you are running on the server. FB, Google etc never claimed to be open source with their infrastructure. So if WhatsApp cant be trusted as to what happens on the server, right now neither can Signal. Can Signal show that what they are running on the server is the same as whats…

You don't need to trust the server with E2E encryption. If you can review and trust the client, the server only has access to the information that the client sends. Even if they release up-to-date server code, we have no way to confirm that's the code that's running on their servers. People would then complain that they don't have shell access to the servers to ensure the code is what is expected.

Actually there's a way to check the code running on their servers. At least Signal claimed that:

Modern Intel chips support a feature called Software Guard Extensions (SGX). SGX allows applications to provision a “secure enclave” that is isolated from the host operating system and kernel, similar to technologies like ARM’s TrustZone. SGX enclaves also support a feature called remote attestation. Remote attestation provides a cryptographic guarantee of the code that is running in a remote enclave over a network.

https://signal.org/blog/private-contact-discovery/

But of course you need published source code and reproducible build.

Re: We can do better than Signal

#289

Post by hiq »

xorcist wrote: post #267
hiq wrote: post #186

Earlier quoted context omitted.

> Moxie, why haven’t you put Signal on F-Droid yet? There's no security benefit in having Signal on F-Droid instead of using https://signal.org/android/apk/ . I don't think Signal would say much if F-Droid distributed this APK directly (instead of a recompiled version with a different signature). It's just complicated to set up, which is why (I think) nobody has done it. > But we have to trust that Moxie is running t…

> There's no security benefit in having Signal on F-Droid instead of I don't know about Signal specifically but there is absolutely security benefits to hosting apks on F-Droid instead of your own home page. F-Droid supports reproducible builds, so you can actively check that their build infrastructure is not compromised. Signal seems to support some kind of reproducible builds on their own. Why that has not been int…

> Moxie has been quite clear that Signal is not to be distributed on F-Droid, that seems not likely to change.

IIRC his main arguments were really a different signature and delays in updates.

Since these reasons will not exist anymore in the case of reproducible builds (the Signal app could still prompt for updates itself) from Signal being distributed on F-Droid, I don't think we can assume that Signal would not be fine with the APK distributed on F-Droid.

From a quick glance, the main reason left now seems to be that Signal still relies on the Play services libraries at compile-time (not necessarily at runtime), which are proprietary and thus not acceptable for F-Droid. Signal does not want to support a fork with these libraries completely removed.

Re: We can do better than Signal

#290

Post by zamadatix »

xrisk wrote: post #56
zamadatix wrote: post #51

Earlier quoted context omitted.

Wouldn't it just take 1 person doing the verification on a new message to catch this though?

Not if it's targeted towards a particular pair of people.

There is some key exchange, pregeneration, and signing smarts involved with the server for all new communications at the initial connection. The net result is either everyone on your contacts was faked or nobody was (or you get a message when only 1 is intercepted on conversation setup).

That being said it's possible for all of Bob's contacts to have been MITM but not all of Carol's so each person does have to check at least one conversation to be sure.

Post reply on HN