5 ms·

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:

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 12y ago
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 12y ago
  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 12y ago
    > 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 12y ago
      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 12y ago
        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?

Canada 12y ago

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 12y ago
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 12y ago
  > 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 12y ago
    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 12y ago
      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?