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

Looking back at how Signal works

signal.org

Post reply on HN
Print view View original

281–290 of 301 posts

Re: Looking back at how Signal works

#281

Post by kagenouta »

psexec wrote: post #217
kagenouta wrote: post #168

Earlier quoted context omitted.

I, for one, have a bigger problem with it forcing the use of phone numbers as a sign-in method. They're an arbitrary identifier from a legacy system that there's not really a point in continuing to extend, because if your device is capable of anything more advanced than SMS it's also capable of... well, this. Also KaiOS and the like are making chat feasible even on feature phones. Don't get me wrong, RCS will be a fi…

"even on feature phones"? It was perfectly possible at least back in the early 2000's. Where I'm from, we've gone through a lot of different IMs over the years, including XMPP (which I was a big fan of, but started to despise because it had such terrible support for mobile clients). Many J2ME clients had pretty advanced features like group chats and file transfers.

Huh, TIL.

Re: Looking back at how Signal works

#282

Post by kagenouta »

fauigerzigerk wrote: post #239
kagenouta wrote: post #209

Earlier quoted context omitted.

Tackling this point separately: the entire reason they do this is because they routinely experiment with side projects and then build the ideas that work well into the services that gain traction. As much as it comes with the drawback of being scattershot in general, it specifically creates a track record for failure with messaging because successful messaging products, as a rule, have network effect - something you…

>As much as it comes with the drawback of being scattershot in general, it specifically creates a track record for failure with messaging because successful messaging products, as a rule, have network effect - something you can't build when you're playing with three different approaches simultaneously. I think what Google needs to do is to seperate the messaging protocol from the messaging software. The protocol need…

Hard agree. I'd also argue that any meaningful antitrust action we may eventually impose on big tech companies should force this.

If the one thing so far that's led the feds to threaten this is that they wanted to build a modern protocol for cross-service messaging, then there's no sane reason we couldn't have asked for that exact thing as a spec.

Re: Looking back at how Signal works

#283

Post by est31 »

the_why_of_y wrote: post #233
est31 wrote: post #30

Earlier quoted context omitted.

> roll their own cryptography Signal did the same thing. They invented their own cryptographic algorithms. https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm And the social graph IS sent to servers by Signal. It's protected only by hashing (trivial to circumvent) and by the Intel SGX technology (a bit harder to circumvent, but I doubt that the US govt can't do it).

Signal's crypto is an incremental improvement of existing algorithms with good reputation, OTR and SCIMP. Telegram's crypto is reportedly designed from scratch, with questionable choices such as SHA1 and MAC-then-encrypt. https://www.cryptofails.com/post/70546720222/telegrams-crypt... https://eprint.iacr.org/2015/1177.pdf

I didn't want to claim that Telegram's crypto was better or as good as Signal's. But saying that Telegram rolled their own crypto while Signal did not is misleading as both designed their own protocols.

Also, Telegram uses SHA256 now in the places relevant for security, so that point was resolved.

Re: Looking back at how Signal works

#284

Post by mekster »

gonehome wrote: post #26
K2L8M11N2 wrote: post #14

Earlier quoted context omitted.

In most European countries you need to submit your ID to get any sort of working SIM card.

If that’s the case doesn’t it matter even less that signal requires it since it’s already known anyway? Signal’s use of phone numbers as IDs means they don’t have to have any of your contacts sent to their servers. As shown in the article they have no metadata and nothing to reveal beyond your phone number and when you signed up. These other apps send your social graph to their servers, track and store metadata, don’…

Signal can have a great interest in buying up private data linked with phone numbers and add people that they chat with with their phone numbers, sell again with the added data.

Re: Looking back at how Signal works

#285

Post by bsaul »

spians wrote: post #254
bsaul wrote: post #232

Earlier quoted context omitted.

Never tried Signal, but from what you're telling, it seems that they redevelop the core functionalities for each platform. That's interesting, because i've been looking for a way to share core logic code across platform (mobile & desktop at least), and still haven't found something really user friendly. From my brief lookup (rust & gomobile are the ones i've looked at), it seems that most dev environment seem to supp…

Honestly there are no perfect solutions to this. There are cross platform frameworks (React Native, Xamarin etc) that you can try but you'll definitely hit the wall when trying to access low level native APIs. Kotlin Multiplatform seems to be the step in the right direction. It has first party support on Android and works seamlessly for Android apps, but it's too early to tell for the other platforms. In an ideal sce…

I’ve heard of people running all the logic in a self-contained local http server (developped in whatever language) then rely on local socket connection + protobuf for communicating between the native and the cross-platform codes.

i had hoped some people here would chime in with this trick, but it doesn’t seem like it

Re: Looking back at how Signal works

#286

Post by pthatcherg »

_emacsomancer_ wrote: post #139
fish45 wrote: post #131

Earlier quoted context omitted.

The desktop was pretty terrible for me (on Linux) for until a few months ago, but now it works perfectly. The only thing missing is sms from the desktop but from what I understand Signal won't ever add that because sms isn't secure

there's still no call/video from the desktop, no?

I work on calling for Signal, and the last few months we have been working on desktop calling. It's nearly ready and will hopefully be in public beta in a matter of weeks, and (again, hopefully) fully available in a few months.

Re: Looking back at how Signal works

#287

Post by _emacsomancer_ »

pthatcherg wrote: post #286
_emacsomancer_ wrote: post #139

Earlier quoted context omitted.

there's still no call/video from the desktop, no?

I work on calling for Signal, and the last few months we have been working on desktop calling. It's nearly ready and will hopefully be in public beta in a matter of weeks, and (again, hopefully) fully available in a few months.

This is excellent news. (Desktop calling would include video calls, right?)

Re: Looking back at how Signal works

#288

Post by phyzome »

Aachen wrote: post #247
StavrosK wrote: post #66

Earlier quoted context omitted.

What is it? Riot works beautifully.

Beautifully mediocre, but yeah it mostly works. (Never been able to use Signal so I can't compare, but Riot's encryption was completely broken until a few weeks ago, and now there is only the occasional "hold on, gotta fetch keys for 10 seconds" and slow scrolling up, etc. It can't compete with something like Telegram in terms of UX; it is infinitely better for privacy but it doesn't "work beautifully".)

It was a non-stop shitfest of buggy encryption and broken UX last I tried. A group of us tried using it for a bit and gave up because we kept losing messages, couldn't figure out which messages were "secure" in various ways, and had confusing horizon effects where only some people could see some messages.

That was a couple months ago. Maybe it has improved massively since then? I guess I'll try it again later this year.

Re: Looking back at how Signal works

#289

Post by Aachen »

phyzome wrote: post #288
Aachen wrote: post #247

Earlier quoted context omitted.

Beautifully mediocre, but yeah it mostly works. (Never been able to use Signal so I can't compare, but Riot's encryption was completely broken until a few weeks ago, and now there is only the occasional "hold on, gotta fetch keys for 10 seconds" and slow scrolling up, etc. It can't compete with something like Telegram in terms of UX; it is infinitely better for privacy but it doesn't "work beautifully".)

It was a non-stop shitfest of buggy encryption and broken UX last I tried. A group of us tried using it for a bit and gave up because we kept losing messages, couldn't figure out which messages were "secure" in various ways, and had confusing horizon effects where only some people could see some messages. That was a couple months ago. Maybe it has improved massively since then? I guess I'll try it again later this ye…

Definitely improved somewhere last month. Not bug-free by a long shot, but while I also gave up on it after trying it in February, I'm now using it in favor of Keybase that got bought by some shitcorp.

Re: Looking back at how Signal works

#290

Post by yencabulator »

mycall wrote: post #280
garrett_oh wrote: post #272

Earlier quoted context omitted.

Even without verifying safety numbers, you’re still better off on Signal then you would be on another platform that doesn’t even offer the option of verification. If you’re looking to MITM a conversation on Signal you can only guess whether or not the recipients have verified each other, whereas on a platform like iMessage you know they haven’t because it’s not an available option.

SS7 spoofing is not a hard thing to do. Who knows if you really are initiating to +14055551212 who you think they are. I guess using multiple techs in serial could obfuscate the initiation correctly (voice, IM, Social Media, etc)

PGPFone had a neat thing where it'd show each participant of a voice call a short string they'd read out loud, and then the crypto would use those for handshaking. MITM'ing voice, as part of a freeform conversation, especially between friends, is a lot harder.
Post reply on HN