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

Disappearing messages for Signal

whispersystems.org

Post reply on HN
Print view View original

181–187 of 187 posts

Re: Disappearing messages for Signal

#181

Post by lorenzhs »

lenish wrote: post #178
lorenzhs wrote: post #166

Earlier quoted context omitted.

That's still not the problem considered here. You're not asking "does anyone have the key I'm seeing here", you're asking "does this person next to me have the key I'm seeing here". No birthday paradoxes of any kind involved.

Forgive me, as I haven't used signal, but I don't see how whether they are sitting next to you or not changes the problem. If I can generate a key that hashes to the same value as your key, I can convince anyone I am you. If I can generate a second collision for a third party's key, I can convince you you are talking to that third party, as well. Generating hash collisions is, as I understand it, pretty well modelled…

Right, sorry, I misunderstood. A preimage attack (that's the technical term for this) could indeed be modeled as a birthday problem with a fixed day ("someone with the same birthday as me"). This is much harder than finding a normal collision (two objects with the same hash, two people with the same birthday), though.

Re: Disappearing messages for Signal

#182

Post by shshhdhs »

SideburnsOfDoom wrote: post #142
1024core wrote: post #100

Earlier quoted context omitted.

What if the person you're chatting with does not want it archived? (I'm not questioning, but wondering what a protocol would be)

Suppose that you are chatting to me. You don't want your messages archived in any way. I really want to keep records, so I have a second device, and take a picture of the screen every time I get a message of you. There is no software or protocol that can entirely eliminate this human problem. The two parties have to have some level of agreement and trust.

This is also why Data Loss Prevention software is truly useless in an employee environment. Sure it can spot you forwarding email, but I can take a picture of the email with my phone.

Re: Disappearing messages for Signal

#183

Post by throwaway7767 »

mahyarm wrote: post #54
AckSyn wrote: post #50

Now if they would drop the ridiculous requirement of having a phone number and go with usernames and not require access to my contact list like most other services, you could actually be safer and not rely on _their word_ alone.

The app is open source and you could do something like a proxy or similar if you really want to be sure of what get sent from your client. The server is also open source too. As moxie said, it's about raising the defaults of the world, not about making it secure for the crypto nerd.

> As moxie said, it's about raising the defaults of the world, not about making it secure for the crypto nerd.

The thing is, the attacks in the "crypto-nerd paranoia" category tend to become everyday attacks over time. Pre-Snowden, most people would put a lot of the things the NSA is doing into the "crypto-nerd paranoia" bucket. Now we know they were wrong to do so.

Signal routes all conversation metadata through one infrastructure, which becomes a very tempting target. By also requiring phone numbers as identity, they make it very easy to tie that metadata to real people and perform graph analysis on it.

Re: Disappearing messages for Signal

#184

Post by Siimteller »

terraforming wrote: post #123
moxie wrote: post #104

Earlier quoted context omitted.

Wire does not use Signal Protocol, they used some of our code to create a protocol of their own devising that we do not recommend.

Why do you not recommend? Hopefully you're not just saying that because they aren't Signal.. ------------------------------------------------ I've been using Wire for a few weeks now and I'm absolutely happy. They recently released a linux client https://medium.com/wire-news/get-your-linux-on-999403a1a4fe#... (not a chrome app!) (though I think it's electron). I'm quite happy with them, give them a try.

Correct, built with Electron like our Windows and macOS apps. Glad you're enjoying it.

Possible reason: https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7...

Re: Disappearing messages for Signal

#185

Post by drudru11 »

subliminalpanda wrote: post #31
drudru11 wrote: post #28

How do they make money?

From wikipedia: "The group is funded by a combination of donations and grants, and all of its products are published as free and open-source software." https://en.wikipedia.org/wiki/Open_Whisper_Systems

Why isn't this on their site? ... this is just thinking out loud, not directed at you.

Re: Disappearing messages for Signal

#186

Post by kelnos »

Johnny_Brahms wrote: post #161
kelnos wrote: post #150

Earlier quoted context omitted.

Unless this is some non-standard variant, ZRTP only negotiates a key exchange for use when encrypting the audio packets (the 'S' in 'SRTP'). Neither of those protocols has anything to do with codec selection, which is done via a SDP sent over SIP, or some other signaling protocol.

Sorry. I should just shut up about things I don't know much about. I thought the rtp part did negotiation, since they specify a "payload type" field and remembered the zrtp config in jitsi where you can specify codecs, and jumped to conclusions.

The payload type field ends up just letting you do stuff like send RTP events (like DTMF tones) over RTP by sending a different payload type that the other end can interpret in a different way than as being part of your main audio stream. Either way tho, all the payload types that you should expect to see over the channel should be negotiated beforehand, using another protocol.

But no worries... there are a ton of moving parts in these protocols, and even though I've been working with them for a while, I still tend to forget details here and there, too.

Re: Disappearing messages for Signal

#187

Post by kelnos »

kuschku wrote: post #159
kelnos wrote: post #157

Earlier quoted context omitted.

> If they can’t fork it while still using your servers, and you refuse to allow federation, how the FUCK is it open in any way? "Open" doesn't mean you get to use someone else's servers. It just means that the code is there and you can make use of it in your app. There are a ton of things in that code that are valuable and useful as open source beyond the line that lists the URL of their servers.

The whole point of Signal is that it trades a little bit of security away, and in turn you get something everyone can use. If you fragment the user base, you throw exactly that away. Because no user is going to be willing to install 20 Signal forks to talk to all their friends. So, in practice, Signal is either at most visible source, or it's actually destructive to the average person's message security. The only adv…

I don't disagree with you, but the reality of running an API service in the cloud means it's tough to support more than just your own clients if you don't have a large budget. And it's easier to coordinate breaking changes if you have control over both the client and server.
Post reply on HN