
TextSecure's Private Group Messaging - FredericJ
https://whispersystems.org/blog/private-groups/
======
codelike
I'm a big fan of TextSecure and recommended it to all my friends, both those
in IT and 'normal' people. Usually, I managed to convince them that the open
source nature of TextSecure and the crypto experts behind it (e.g. Moxie) make
it more secure than Threema/... . However, the more sceptical ones among my
friends always asked two questions, which I didn't have a good answer for:

1\. What is TextSecure's business model? Who pays for the server
infrastructure?

2\. Doesn't WhisperSystems belong to Twitter? Twitter is a US-company (and
also part of the NSA stuff), so why should I use that kind of software? [Edit
for clarification: I'm from Germany, where the US/Twitter affiliation is seen
as a downside by some people].

It would be great if TextSecure/Open Whispersystems publicly addressed these
points. I have seen that there's a reply from Moxie here:
[http://support.whispersystems.org/customer/portal/questions/...](http://support.whispersystems.org/customer/portal/questions/5836104-how-
is-openwhispersystems-paying-for-the-its-server-costs-)

but these two questions are so central that they deserve more attention than a
reply in the support forum. From a technological point of view, TextSecure
wins hands down. Now it's time to convince those who are still skeptical
because of other reasons.

Just to be clear: I want TextSecure to become successful. I'm a big fan.
That's why I'm mentioning this: in order to help spread the word.

~~~
moxie
> 1\. What is TextSecure's business model? Who pays for the server
> infrastructure?

It's a good question. TextSecure is not a business, so we don't really have a
business model in the traditional sense. Open Whisper Systems is a collective
project made up of volunteers and a growing number of contributors, who are
sometimes paid by donations
([https://whispersystems.org/blog/bithub/](https://whispersystems.org/blog/bithub/))
and grants.

Thus far, we've been able to smoothly fund the server infrastructure through
grants and donations as well. I think we'll probably be able to continue that
way indefinitely, but if that ever changed for any reason, we would consider
charging small amounts for premium or high cost features like extremely large
attachments. But in general, Open Whisper Systems is a project rather than a
company, and the project's objective is not financial profit. I know that's a
difficult thing to explain.

> 2\. Doesn't WhisperSystems belong to Twitter? Twitter is a US-company (and
> also part of the NSA stuff), so why should I use that kind of software?

This is also confusing, but Open Whisper Systems is not Whisper Systems. Open
Whisper Systems has no relationship with Twitter at all, and is a different
organization that came together to facilitate development of the Whisper
Systems software which was released under GPLv3. Twitter has never contributed
money or resources to Open Whisper Systems, and is not in control of any of
the infrastructure.

~~~
swaits
I'd pay good money for an iOS version. I'm limping along with Threema now
(which, functionally, is really great!).

I'd pay even more good money for hosting to not be in Google's data centers.

~~~
jlund
An iOS version is in progress and should be released in the next few months
[1].

The TextSecure servers are _not_ hosted in Google's data centers. Google's GCM
push messaging framework is used to deliver messages to Android users, but the
GCM payloads are fully encrypted.

[1] [https://github.com/WhisperSystems/TextSecure-
iOS](https://github.com/WhisperSystems/TextSecure-iOS)

~~~
swaits
I know it's in progress. I'm anxiously waiting. If you tell me where I can
send $ or BTC to help it go faster, I'll gladly oblige.

~~~
whyever
See [1] for donating BTC and [2] for donating other currencies through the
Freedom of the Press Foundation.

[1]
[https://whispersystems.org/blog/bithub/](https://whispersystems.org/blog/bithub/)

[2] [https://pressfreedomfoundation.org/](https://pressfreedomfoundation.org/)

------
seertaak
I've been using TextSecure for my private messaging and am a big fan.

I can't wait for WhisperSystems to release the iPhone version of the app -- at
that point, all my family's communications will go through TextSecure.

------
davidroetzel
I would love to have a console or even web client for this.

Or is anyone aware of a secure group chat application to replace IRC (or SILC
for that matter)?

~~~
phaer
As far as I now, there is a in-browser client (a browser extension, iirc) in
development.

Your second question is harder. I don't know of a better solution than a self-
hosted jabber-server with https.

------
throwaway41597
This is great! And I love TextSecure.

But I wish it didn't send my contact list to its servers and store them in
perpetuity [1]. Has it be considered to use:

1\. text message history with a contact to derive a key between two contacts?

2\. adding metadata to text messages to discover the sender uses TextSecure?

By (1), I mean Alice and Bob may already have exchanged several messages. I
believe there is a lot of entropy in text messages. That should be leveraged
during the key exchange. In addition, you'd also use WhisperSystems's servers
as another channel, so the mere possession of the text history doesn't allow
an attacker to guess the key.

(2) would only be useful when Alice sends her first text to Bob. She would for
example hash(text_message + "I use TextSecure"), then append the encoded hash
to the text and finally send it. The encoding could be white spaces for 0 and
tabulations for 1. The size of the hash could be as small as 8 bits, because
adding 8 trailing spaces/tabs to a text is so rare in real life. Once Bob
receives the text, he can reasonably assume Alice uses TextSecure and then
start the regular key exchange.

[1]: [https://whispersystems.org/blog/contact-
discovery/](https://whispersystems.org/blog/contact-discovery/)

~~~
Canada
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 every 12 hours.

The TextSecure-Server does not store these hashes of your contacts. Of course,
we can't know for sure what any particular instance does. It could be modified
to log that info.

Metadata is in fact added to text messages to discover other TextSecure users.
You can exchange encrypted messages over SMS and MMS with users who are not
registered on the server or with users who are registered on another server.

~~~
throwaway41597
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 space huge.

Texts have a lot of entropy. From an scrypt slide "Entropy estimated according
to formula from NIST: 1st character has 4 bits of entropy; 2nd–8th characters
have 2 bits of entropy each; 9th–20th characters have 1.5 bits of entropy
each; 21st and later characters have 1 bit of entropy each". So a
140-character text has about 156 bits of entropy, excluding the date the text
was sent which probably adds some 20 bits.

It's too bad not to use that both during the discovery and the key exchange.

Same thing for RedPhone, it could leverage the call log between Alice and Bob.

~~~
Canada
> 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?

~~~
throwaway41597
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.

~~~
Canada
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?

~~~
throwaway41597
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.

~~~
Canada
> 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!

------
pnathan
" ephemeral signing key pair along with K. ... hash-ratcheting K and including
a signature in the transmitted ciphertext."

Can someone knowledgable comment about the crypto protocol here and how this
provides guarantees that ensure the server can't reverse the messages for
multicast (am happy to read academic papers here too)?

------
fossuser
On somewhat of a meta-HN note it seems strange to me that every one of
kaeporan's comments has been heavily downvoted. Seems unnecessary - maybe the
downvote karma threshold needs to be raised again? To 1000?

------
scl_md
which application should I use if I have an iphone? (and do not want to change
the iphone) what program would you recommend? thank you very much

~~~
dm2
I think TextSecure is coming to iPhone soon, so just wait.

------
a159482a
If it were to be HIPPA compliant, like Medigram, then it potentially could be
useful for health practitioners as well.

------
zokier
I wished moxie would have discussed more the group management aspects.

> Anyone can create a group, name it, give it an avatar icon, add members, and
> then everyone can chat together with a normal asynchronous experience.

Does this mean that any group member can add more members? Are there any IRC-
like moderation features (even planned?), eg. privileged members who can
remove users from group? Is there support for persistent groups (ie IRC
channel equivalents)?

~~~
liliakai
TextSecure groups are fully egalitarian. Anyone may add members and no one may
force an existing member to leave. There are no privileged members.

A group conversation persists locally on your own device unless you delete it,
just like a normal conversation. The server does not store any records
representing the group, so there's nothing to persist beyond the clients.

There is no plan to change these properties, afaik.

------
secfirstmd
Awesome, look forward to using it!

------
kaeporan
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 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.

That said, I strongly respect Open Whisper Systems. They usually release very
well thought-out material. Perhaps they should have paid more attention though
to this particular issue.

~~~
tptacek
This post says that TextSecure implements transcript consistency in the
protocol, and in a fashion objectively superior to that of mpOTR: the
TextSecure protocol can provide continuous consistency checks, while mpOTR can
do so only when the session is torn down. What the TextSecure client does not
yet do is provide a UI for that feature of the protocol.

Further, it's hard to understand how transcript consistency could be a serious
objection while _lack of forward secrecy in the messages_ isn't, especially
given the deniable messaging semantics of OTR.

So, to address your concluding sentence directly: it seems to me like Moxie
has paid more attention to this issue than you have.

~~~
kaeporan
I'm quite certain that the current TextSecure chat allows my proposed scenario
with Alice, Bob and Carol to go through without issue. This is the main
problem here. So while transcript consistency is discussed in the blog post,
it remains the case that Alice can send a different message to Bob and Carol
without being detected.

~~~
tptacek
This is a comment you could have written without even reading my comment. You
haven't responded to anything I just wrote. I'm not surprised; your function
in TextSecure threads seems to be to pop out and complain about TextSecure
without mentioning that you're the author of Cryptocat, a competing (and
inferior) offering.

~~~
kaeporan
I think TextSecure is an excellent and inspiring project. All I'm trying to do
is identify an area of concern for me. I'm not sure why you're attacking me
personally here. I think my initial point of concern stands and I hope the
TextSecure developers will work on addressing it.

And yes — I believe my work on Cryptocat does grant me some helpful
perspective on the kind of issues faced in group chat. I'm more than happy try
my best to offer some insight to other great open source projects. If I wanted
to sneakily hide that I work on another encrypted messaging project (why would
I? Open source projects discuss issues with one another all the time) it would
have been simple for me to create another username.

~~~
tptacek
I'm not attacking you personally. I object to the fact that you didn't lead
with the fact that you compete with TextSecure. As for your tone regarding the
TextSecure project, here are all your messages regarding TextSecure:

[https://hn.algolia.com/?q=author%3Akaeporan#!/comment/foreve...](https://hn.algolia.com/?q=author%3Akaeporan#!/comment/forever/0/author%3Akaeporan%20textsecure)

I am, however, happy to attack your _project_ , Cryptocat, which I believe to
be incompetently interviewed, debugged into existence, and dangerous to its
users.

Finally, you _still_ haven't responded to my comment upthread.

~~~
kaeporan
I'm sorry, but I don't think your approach to this discussion is constructive.
I hope TextSecure developers address my initial concern, and that's all for
me.

~~~
tptacek
mpOTR sacrifices forward secrecy and provides transcript consistency with
limited semantics, which has the side effect of making the "transcript
integrity feature" trivial to implement, because the protocol supports only a
silly version of it. mpOTR clients can't simply fix this with UI, because
these are properties of the protocol.

The TextSecure protocol retains forward secrecy at the message layer and
provides _continuous_ transcript integrity. The TextSecure client hasn't
worked out the UI for it, but the protocol supports it. TextSecure can provide
continuous transcript integrity with a UI update --- something mpOTR clients
can't do _at all_.

But here you are, sniping at TextSecure for lacking a UI feature that you've
implemented a minimal and un-useful version of. Then, when called on it, you
retreat to a position of "I'm inspired by TextSecure and am just trying to
help". As if, after blogging about why transcript integrity is literally one
of the reasons TextSecure doesn't use mpOTR, they were unaware of the
importance of the feature.

mpOTR is a dead end. It's unfortunate you invested in it, but that is what it
is.

~~~
makomk
It doesn't matter what kind of transport integrity the underlying protocol has
if that integrity information isn't actually used. What's more, it's not just
that they haven't got around to implementing UI for it, the problem is they
can't figure out _how_ to meaningfully expose that information in the UI -
which, with consistency semantics this complicated, is actually the hardest
part of the problem! They don't even really have the outline of a solution,
let alone the transcript integrity you're claiming they have. Yet here you are
treating their vapourware as though it provides more protection than something
that actually exists.

~~~
tptacek
The UI for transcript consistency is absolutely not the hardest part of the
problem. We are comparing an existing UI on top of a broken transcript
consistency feature to a nonexistent UI on a functional, extant transcript
consistency protocol. I am objecting to the notion that an extant UI built on
a mound of sand somehow trumps a concrete foundation poured for a better UI.

This is apparently so much the case that Nadim has acknowledged _jettisoning
his existing protocol_ to come up with a new protocol that will support it.

You could disagree with me, but I don't think you can do so without
acknowledging that the comment that introduced this issue to the thread was...
let's say "not fully informative".

~~~
kaeporan
UI is absolutely a very difficult part of the problem, and here we see an
example outlining this. Even a capable protocol still has problems if the UI
fails to translate the capabilities into benefits and security increases for
users. I speak from experience: Cryptocat has had some serious issues that
were due simply to incomplete UI, the most recent of which was related to
authentication.

Also, the reason for us moving to a new protocol has more to do with formal
security proofs than being able to adopt new properties.

~~~
tptacek
This is a comment that appears to _endorse_ mpOTR's broken transcript
consistency feature. Also: formal security proofs? Really?

Some context:
[http://tobtu.com/decryptocat.php](http://tobtu.com/decryptocat.php)

(Yes, we know you addressed these issues; the page I just linked to says
that).

~~~
kaeporan
It really seems like you wrote this comment not to add anything to the
conversation, but simply to discourage me from commenting. I really don't
understand. I'm trying to be constructive here and I wish you'd join me. Your
comment right now just flails around for abrasive things to put together into
a statement that is completely incoherent and off-topic.

~~~
tptacek
Your inability to respond to my actual comments appears almost willful. Let's
break this down:

* You complained about TextSecure's "lack" of transcript integrity.

* I pointed out that transcript integrity was a prominent feature of the blog post we're talking about, and a feature that the actual TextSecure protocol does vastly better than mpOTR.

* Someone else objected to allusions to TextSecure's transcript consistency feature as vaporware, given that Cryptocat actually has a UI for this.

* I pointed out that the protocol Cryptocat builds that UI on is so bad that you conceded downthread that you're building a new protocol --- you made that concession in _direct response_ to my point about mpOTR's inferior transcript consistency.

* Your response is to imply that improved transcript consistency is _not_ a significant reason for abandoning your existing protocol.

* I point out the inconsistency.

* You object that I'm not "adding anything to the conversation".

~~~
kaeporan
Thanks for laying out your thought process, it's very helpful.

> I pointed out that the protocol Cryptocat builds that UI on is so bad that
> you conceded downthread that you're building a new protocol --- you made
> that concession in direct response to my point about mpOTR's inferior
> transcript consistency.

This is the problem. You're assuming that my mention of mpCat was a concession
made in "direct response" to your point about mpOTR, whereas it's actually
brought up as a tangent. The reason we're building a new protocol is to be
able to subject it to formal security proofs, as mentioned prior. It doesn't
have to do with the existing protocol being "bad" or not or its current
integration into the UI.

Regarding my other implied statements, I think it would be better to stick to
claims I am explicitly making instead of assuming implications on my part.
That being said, I apologize and will try to be more clear in my future
comments in order to avoid assumptions.

I'm also not sure why you keep bringing up mpOTR. As I mentioned in my other
post that you refer to, we're not using it anywhere nor do we plan to. We're
building a modified version which is far less bulky, etc.

~~~
tptacek
Maybe some other reader can tell me whether Nadim is saying that he endorses
TextSecure's continuous transcript consistency model and is working on folding
it into his new protocol, or whether he thinks the mpOTR model of consistency
checking only at the conclusion of sessions is so useful that not providing it
is worth dinging TextSecure over, or whether there's some third option I'm
excluding. Because I can't even figure out what Nadim is trying to say
anymore.

~~~
kaeporan
I endorse continuous transcript consistency, but believe that TextSecure
currently does not allow its users to benefit from it and that this should be
resolved. I think mpOTR is irrelevant to this discussion. I hope that's clear!

