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

TextSecure's Private Group Messaging

whispersystems.org

Post reply on HN
Print view View original

91–100 of 109 posts

Re: TextSecure's Private Group Messaging

#91

Post by darklajid »

bgaluszka wrote: post #87
acqq wrote: post #84

Earlier quoted context omitted.

If it's not for profit, why don't you open source the server-side code too? Then those that are interested can rely on their own infrastructure.

I think they do https://github.com/WhisperSystems/TextSecure-Server

Note that you're forking the net with this though. As far as I understood in the posts about TextSecure here:

- You can run your own server

- Your server cannot talk to the 'official' servers

- Federation is somewhat possible, but works on a 'We whitelist your machine' base

It's not XMPP. So people using 'Default' TextSecure and your friends & family on your own TextSecure server would be isolated, as far as I understand.

I'd love to be corrected though, because THAT (not business model/jurisdication) is my reason why I'm not comfortable using/recommending it. No offense to moxie and his team, but for me this is another Threema unless running under my (most likely not competent enough, if we're honest) supervision.

Re: TextSecure's Private Group Messaging

#92

Post by KMag »

kaeporan wrote: post #59
sillysaurus3 wrote: post #52

Earlier quoted context omitted.

If you try to decrypt C with any key other than the K that was used to encrypt it, you'll get gibberish (the decryption process will fail). As far as I know, it isn't possible for an attacker to generate a message ciphertext C such that two different decryption keys would both decrypt to valid plaintexts. There can only be one valid decryption key; trying to decrypt C using any other key would yield random output, wo…

I hope I'm not mistaken, but my understanding is that you can have the same message C that would decrypt with K1 to the plaintext "Hello world" but with K2 to another plaintext of your choice ("Jello Warld" or whatever.)

This is only true for one-time-pad encryption. For a given AES-256 cipher mode and ciphertext C, there are at most 2 * * 256 possible decryptions of C. For most pairs of ciphertext and plaintext (C, M2) longer than 32 bytes, there doesn't exist a key K2 that decrypts C to M2. Even if K2 exists, finding K2 given (C, M2) with an average work factor less than 2 255 implies you've found a weakness in AES-256.

Re: TextSecure's Private Group Messaging

#93

Post by nialo »

tptacek wrote: post #85
avn2109 wrote: post #82

Earlier quoted context omitted.

But crucially, this will still be vulnerable to timing attacks, if I'm not mistaken.

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

There may not be the traditional byte at a time comparison type timing attack, but maybe this is still vulnerable to timing correlation attacks in the same sense that tor is. That is, Google or someone monitoring Google's network can look at all the messages and see who is talking to whom by matching up timing and encrypted message bodies.

Re: TextSecure's Private Group Messaging

#95

Post by tptacek »

infinity0 wrote: post #90
tptacek wrote: post #6

Earlier quoted context omitted.

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 coul…

The post only says that TextSecure have begun implementing this. The hash-parent-pointers is a good start and enables more functionality in this direction, but it doesn't mention other strategies that actually ensure the user's confidence in consistency. For example, checking for others' acknowledgements, heartbeats, or resending a potentially-inconsistent situation. None of this is that hard, but the post is missing…

The thread you're commenting at the top of litigates the point you're making in detail. There's nothing I can say to your comment that I haven't said already.

Re: TextSecure's Private Group Messaging

#96

Post by tptacek »

kaeporan wrote: post #61
sdevlin wrote: post #42

Earlier quoted context omitted.

It seems pretty trivial to me. Can't you just send different messages to different people?

I need to investigate this properly before I offer you an educated answer with details.

Any progress on this, or is 'sdevlin simply correct?

Re: TextSecure's Private Group Messaging

#97

Post by Canada »

throwaway41597 wrote: post #88

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…

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.

Re: TextSecure's Private Group Messaging

#98

Post by e12e »

tptacek wrote: post #85
avn2109 wrote: post #82

Earlier quoted context omitted.

But crucially, this will still be vulnerable to timing attacks, if I'm not mistaken.

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]

Re: TextSecure's Private Group Messaging

#99

Post by throwaway41597 »

Canada wrote: post #97
throwaway41597 wrote: post #88

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…

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

Re: TextSecure's Private Group Messaging

#100

Post by jlund »

acqq wrote: post #83
jlund wrote: post #74

Earlier quoted context omitted.

This isn't entirely true. A detailed explanation is available in the Open WhisperSystems Support Center [1] and several solutions are in the works. Google's GCM push messaging framework is used only for message delivery; the TextSecure server itself is open source [2]. [1] http://support.whispersystems.org/customer/portal/articles/1... [2] https://github.com/WhisperSystems/TextSecure-Server

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 alternatives are being worked on.

Apple also has root access to all iOS devices via their over-the-air update framework. Opaque basebands and graphics chips with closed source drivers are difficult to trust too. None of these scenarios mean that software which offers serious improvements over the status quo should be casually dismissed. TextSecure can (and does) provide significant protection from mass surveillance and targeted surveillance. Security nihilism is corrosive.

Post reply on HN