TextSecure's Private Group Messaging • Hacker News Board

Re: TextSecure's Private Group Messaging

#101

Post by acqq » Wed, May 07, 2014, 8:28 AM UTC

jlund wrote: post #100

acqq wrote: post #83

Earlier quoted context omitted.

It's true currently. At the support page you link first it is promised that it will be eventually changed but now: "Outside of Google's GCM, the fact is that there are no alternative push messaging frameworks for Android that can scale to the millions of users that TextSecure has. GCM requires Google Play." Note, the page confirms: Google Play still has to be installed to use TextSecure on Android. That is the curren…

Full disclosure: I wrote that Support Center article. The comment I was replying to made it sound as though TextSecure's infrastructure is almost entirely Google-based. It is not, and that's what I meant when I said "This isn't entirely true." The server is open source and it already includes preliminary support for WebSockets and Apple's APN push messaging network. Google's GCM is merely one component, and alternati…

So it's still true that currently the sever side uses only Google servers. It's nice to hear that there's work on the alternatives.

What you call "nihilism" is simply the observation of the current state. At the moment Google has root access and all the metadata of all TextSecure users, and currently the user can't configure TextSecure to use some other servers even if he'd prefer to do so. Still I'm glad that I've seen that some server-side code is now open source.

Re: TextSecure's Private Group Messaging

#102

Post by jlund » Wed, May 07, 2014, 4:18 PM UTC

acqq wrote: post #101

jlund wrote: post #100

Earlier quoted context omitted.

Full disclosure: I wrote that Support Center article. The comment I was replying to made it sound as though TextSecure's infrastructure is almost entirely Google-based. It is not, and that's what I meant when I said "This isn't entirely true." The server is open source and it already includes preliminary support for WebSockets and Apple's APN push messaging network. Google's GCM is merely one component, and alternati…

So it's still true that currently the sever side uses only Google servers. It's nice to hear that there's work on the alternatives. What you call "nihilism" is simply the observation of the current state. At the moment Google has root access and all the metadata of all TextSecure users, and currently the user can't configure TextSecure to use some other servers even if he'd prefer to do so. Still I'm glad that I've s…

The server side is currently relaying messages for the in-progress iOS and Chromium clients. That's functionality that exists today, even though the clients are still under development. The TextSecure server is an elegant and important part of TextSecure's infrastructure. I stand by my assertion that it's an oversimplification to say that TextSecure == Google's Servers.

Google does not have access to any metadata, other than the fact that you are a TextSecure user who has received a Push notification. GCM payloads are fully encrypted. Google cannot tell who a message was from, they cannot see which numbers were involved (users are free to register with a number that is different than the one assigned to the cell phone that is running TextSecure), they cannot tell whether or not it was part of a group conversation, and they cannot see its contents.

Re: TextSecure's Private Group Messaging

#103

Post by Canada » Thu, May 08, 2014, 4:27 AM UTC

throwaway41597 wrote: post #99

Canada wrote: post #97

Earlier quoted context omitted.

Reference [1] doesn't describe what TextSecure actually does. The client sends a truncated hash of each contact to the server, and the server responds with the set of matches. The process does attempt to protect your privacy, however the "preimage space" is small, and the server will accept thousands of contacts per directory update so enumeration of TextSecure users is possible. The directory update process occurs e…

Yes my reading of the blog led me to believe they use the naive solution because it only lists solutions which don't work and concludes that TextSecure is too big to use these. Do you mean that TextSecure may send encrypted messages to contacts who don't have it? You didn't address my bullet (1). If Alice has exchanged N texts with Bob prior to installing TextSecure, these messages could be used to make the preimage…

> Do you mean that TextSecure may send encrypted messages to contacts who don't have it?

Of course not. The recipient would see unreadable ciphertext. What I'm saying is that SMS carries some metadata which identifies the message as coming from TextSecure. This enables one TextSecure client to detect the presence of another without the TextSecure-Server, and offer the option of establishing a secure session. In this case key exchange is performed over SMS.

I'm not sure I understand your first bullet point. The preimage space of what? In what way do you propose to use the entropy of text messages or call logs?

Re: TextSecure's Private Group Messaging

#104

Post by throwaway41597 » Thu, May 08, 2014, 3:34 PM UTC

Canada wrote: post #103

throwaway41597 wrote: post #99

Earlier quoted context omitted.

Yes my reading of the blog led me to believe they use the naive solution because it only lists solutions which don't work and concludes that TextSecure is too big to use these. Do you mean that TextSecure may send encrypted messages to contacts who don't have it? You didn't address my bullet (1). If Alice has exchanged N texts with Bob prior to installing TextSecure, these messages could be used to make the preimage…

> Do you mean that TextSecure may send encrypted messages to contacts who don't have it? Of course not. The recipient would see unreadable ciphertext. What I'm saying is that SMS carries some metadata which identifies the message as coming from TextSecure. This enables one TextSecure client to detect the presence of another without the TextSecure-Server, and offer the option of establishing a secure session. In this…

Thanks for replying. My bullet (2) was stupid. Hopefully bullet (1) makes sense.

TL;DR: TextSecure faces a key distribution problem. But texts messages are somewhat secret and are often already stored in each of Alice and Bob's phones. My assertion is these secrets authenticate Alice to Bob and Bob to Alice.

I mean currently it's easy to reverse a hash because there aren't many phone numbers (that was your point, wasn't it?). If you query WhisperSystems (WS) by hash(sender_number + recipient_number + date_sent + text_message), then the hash is much harder to reverse for any long text message. Alice and Bob can both compute the hash and discover whether the other has TextSecure because only they can query this hash to WS. Similarly, they can authenticate each other and exchange keys because only they know their past message history.

Obviously, you wouldn't use text history alone because someone may have been eavesdropping. But these distributed secrets would make WS know much less about its users and could help bootstrap the PKI in my opinion.

Re: TextSecure's Private Group Messaging

#105

Post by Canada » Thu, May 08, 2014, 10:08 PM UTC

throwaway41597 wrote: post #104

Canada wrote: post #103

Earlier quoted context omitted.

> Do you mean that TextSecure may send encrypted messages to contacts who don't have it? Of course not. The recipient would see unreadable ciphertext. What I'm saying is that SMS carries some metadata which identifies the message as coming from TextSecure. This enables one TextSecure client to detect the presence of another without the TextSecure-Server, and offer the option of establishing a secure session. In this…

Thanks for replying. My bullet (2) was stupid. Hopefully bullet (1) makes sense. TL;DR: TextSecure faces a key distribution problem. But texts messages are somewhat secret and are often already stored in each of Alice and Bob's phones. My assertion is these secrets authenticate Alice to Bob and Bob to Alice. I mean currently it's easy to reverse a hash because there aren't many phone numbers (that was your point, was…

You're suggesting that the client submits a hash of the combination of the address (phone number) and something only a legitimate sender would know that has sufficient entropy to act as an effective salt value.

The problem I see with using text messages for that is that Alice and Bob very likely have not exchanged messages before. Or they have but those messages are no longer on the device because they have been deleted. Or Bob just bought a new device.

A variation of the idea is using the contact name. It's more reasonable to expect the sender to know the name and address of the recipient, but that has problems too: It would require the sender know the exact spelling of the recipients name (eg. Robert? Bob? Rob?) Also, while hash(name + address) is harder to crack than hash(address) it's not that hard for anyone who knows the value of address. The server knows this, so the server operator would be in a position to figure out names for nearly everyone. The server would also function as an oracle for anyone who knows a number and suspects a name, or knows a name and wants to scan for the number. That's even worse than allowing for enumeration of registered addresses.

Does that make sense or am I missing something?

Re: TextSecure's Private Group Messaging

#106

Post by throwaway41597 » Fri, May 09, 2014, 7:55 AM UTC

Canada wrote: post #105

throwaway41597 wrote: post #104

Earlier quoted context omitted.

Thanks for replying. My bullet (2) was stupid. Hopefully bullet (1) makes sense. TL;DR: TextSecure faces a key distribution problem. But texts messages are somewhat secret and are often already stored in each of Alice and Bob's phones. My assertion is these secrets authenticate Alice to Bob and Bob to Alice. I mean currently it's easy to reverse a hash because there aren't many phone numbers (that was your point, was…

You're suggesting that the client submits a hash of the combination of the address (phone number) and something only a legitimate sender would know that has sufficient entropy to act as an effective salt value. The problem I see with using text messages for that is that Alice and Bob very likely have not exchanged messages before. Or they have but those messages are no longer on the device because they have been dele…

Yes that's about it.

I disagree about the likelihood that messages or phone calls were exchanged prior to installing TextSecure. And restoring the SMS database after purchasing a new device is not impossible. But I agree that names and addresses wouldn't work, although I didn't suggest so.

My point was that it would improve on the status quo, at least for people you care most about (the ones you've talked to, the texts you didn't delete). And once the hashes are hard enough to reverse, you can have a federation of TS servers, because it becomes less risky to share them with an untrusted party. Maybe the improvement would only be marginal after all.

Anyway thanks for the discussion.

Re: TextSecure's Private Group Messaging

#107

Post by Canada » Mon, May 12, 2014, 8:53 PM UTC

throwaway41597 wrote: post #106

Canada wrote: post #105

Earlier quoted context omitted.

You're suggesting that the client submits a hash of the combination of the address (phone number) and something only a legitimate sender would know that has sufficient entropy to act as an effective salt value. The problem I see with using text messages for that is that Alice and Bob very likely have not exchanged messages before. Or they have but those messages are no longer on the device because they have been dele…

Yes that's about it. I disagree about the likelihood that messages or phone calls were exchanged prior to installing TextSecure. And restoring the SMS database after purchasing a new device is not impossible. But I agree that names and addresses wouldn't work, although I didn't suggest so. My point was that it would improve on the status quo, at least for people you care most about (the ones you've talked to, the tex…

> restoring the SMS database after purchasing a new device is not impossible.

Neither is comparing key fingerprints, but 99% of users are unwilling to do so.

> Anyway thanks for the discussion.

Looking at the docs and blog posts may give you the impression that certain things are done, when in actuality they're not.

For example, the TextSecure-Server does include federation related code, but implementation is definitely not complete yet. It's not clear to me whether or not all design decisions have even been finalized yet.

I encourage you to write up your idea more formally and post it on the WhisperSystems mailing list. Just don't wait too long, or Moxie and his gang of contributors will just decide what to do and push working code before you know it!

Re: TextSecure's Private Group Messaging

#108

Post by avn2109 » Tue, May 13, 2014, 12:24 AM UTC

e12e wrote: post #98

tptacek wrote: post #85

Earlier quoted context omitted.

What's the specific timing attack you're considering here?

I'm guessing: I send a message, you receive a message -> possible to infer (with some confidence) that I messaged you? (I don't know if that would be feasible, but I suppose that's what avn2109 meant). [ie: not a timing attack, but traffic analysis]

Good point. I did indeed mean traffic analysis, not "timing attack."

Re: TextSecure's Private Group Messaging

#109

Post by sc00bz » Thu, May 15, 2014, 11:07 PM UTC

sdevlin wrote: post #40

kaeporan wrote: post #2

The fact that transcript consistency is waved aside, despite being an essential property of a messaging protocol especially in a group context, is problematic, from my perspective. Consider a group chat between Alice, Bob, and Carol. With this protocol, Alice can selectively send different messages to Bob and Carol with both of them thinking they got the same message. For example, Alice can tell Bob "The funds were t…

> For example, Alice can tell Bob "The funds were transferred, thanks!" and tell Carol "Bob is stealing money." — and the protocol will ascribe integrity to the messages for both participants and label them as the same message. Isn't this trivially possible in Cryptocat for anyone who controls the server?

> Isn't this trivially possible in Cryptocat for anyone who controls the server?

Yes this is a known bug since August 2013. When I found it and reported it. This was "patched" but if Mallory controls the server it is still possible. There were three ways to do this: block (which just doesn't send messages to blocked users), silent drop when invalid MAC, and silent drop when invalid tag. Block was turned into ignore and these three cases now display a warning message stating something about integrity.

I seem to not be able to find me or anyone stating that "if Mallory controls the server it is still possible". So I guess it was only said in person. Technically it's known but not publicly known :).

P.S. This was a "clamp the artery until the mpOTR protocol is finished".