The first (A) is that TextSecure truncates SHA-2 hashes and, particularly, HMAC-SHA2 MACs. MAC truncation is extraordinarily common and is a design goal for most authenticated encryption schemes. So far as anyone knows, truncation of SHA-2 hashes and HMAC-SHA2 MACs is completely safe; that is, HMAC-SHA2 isn't somehow less safe when truncated than GCM or Poly1305.
The second (B) is that the authors believed TextSecure to have swapped some of the parameters for the HMAC algorithm. Moxie has asserted that this is a mistake by the paper authors, and that TextSecure uses HMAC conventionally.
The third (C, and most of the rest of the paper) is an identity misbinding attack. An identity misbinding attack happens when it becomes possible for Mallory to present Alice's public key to Bob instead of her own, and have Bob reply with a message encrypted to Mallory-seeming-Alice. Mallory can't decrypt the message, but because it's encrypted to a key Alice has, Alice might act based on the message contents. Identity misbinding problems are endemic to public-key cryptography. They are a real issue for protocols in which computers chat with each other and take action (like, authorizing an HTTP request) based on identities. They are less of an issue in chat protocols. Of particular importance, contextually: every other chat protocol has much, much worse key management problems.
Brian Smith says that this paper has value as part of a formal conversation about the security properties of TextSecure. I'm not qualified to evaluate that statement. I don't see anyone saying the paper has practical import for TextSecure or its users. TextSecure remains the best thing out there, I think.
Neither (A) nor (B) are concerns. In (B), the authors are just unfamiliar with HKDF. HKDF is a standard way to use HMAC for key derivation (RFC 5869).
(C) is the observation that you could lie and claim someone else's fingerprint (print it on your business card, for example). This doesn't accomplish much, but is a general issue with fingerprints (e.g. OTR, SSH).
You can try to bind more of the context (e.g. hash more identifying information into the session key or MAC), but this makes things rigid, particularly if parties might be contacted under aliases (e.g., imagine if SSH servers needed to be configured with all possible DNS names they might be contacted under, and rejected others).
But even then, you can't 100% prevent this - if the protocol "binds" the phone number, you can lie and claim someone else's phone number, or name, etc.
(B) Used to be correct (there were some constants used in the HMAC constants which are supposed to be 1/2, but were actually 0/1, of course this makes no difference practically to security), but this has been changed in more recent versions.
> The second (B) is that the authors believed TextSecure to have swapped some of the parameters for the HMAC algorithm. Moxie has asserted that this is a mistake by the paper authors, and that TextSecure uses HMAC conventionally.
(C) costs little more than an extra round-trip - a verifying call from Alice to Bob, before she acts. After receiving the message from Mallory who is impersonating Bob, Alice simply sends Bob a nonce encrypted under Bob's public key. Bob performs a simple operation on the nonce, re-encrypts it with Alice's public key and sends it back to her, thereby verifying that he holds his private key.
This sort of analysis underscores how different TextSecure is from the growing number of snake-oil/backdoored messaging applications out there.
Kudos to moxie and team for building usable free software; it's so much harder to build something that people can use than it is to criticize others' work.
It's a pain that it supports SMS. I wish they would make a TextSecure that completely dropped all SMS sending support. As it is, having legacy SMS makes it trickier to use than Whatsapp, since Textsecure "randomly" sends SMSs (e.g. when your data drops out). If SMS cost you money then this is a deal breaker for using it with less tech-savvy family members.
So obviously that's not the ideal solution, the ideal solution is to have an option to disable sending SMSs. Most people (at least in the US) have unlimited or nearly unlimited SMS with every plan, so sending an SMS doesn't really matter. For those that it does matter for, they could simply disable SMS. In fact, this is such an obvious solution that I went to check if it was there already and what do you know? It is. "Allow outgoing SMS to" has an a checkbox to allow outgoing SMS, to prompt before sending and SMS to another TextSecure user, etc.
I know that, and I can fiddle with settings and get it working as I like. Family members less so.
There are many data plans in Europe where SMS are charged at rip off rates, and are something to be avoided. Even just the risk of sending SMS is enough to put anyone off using the application. Especially when competing solutions work as expected - i.e. they will not send SMS at all, ever.
Or you could just go to the "Allow outgoing SMS to" setting and uncheck the box that says "TextSecure users", or leave it checked and check the box which sais "Ask before sending SMS".
I'm still not invested into any IM solution. Running an xmpp server for my family (parents, wife, me - everyone else cannot use that because they're on Hangout or FB or Whatsapp etc..).
TextSecure certainly seems the best option, but its adoption wouldn't help me a lot (I could migrate my wife, my parents - but I most certainly won't be able to use it beyond that circle) and - I really, really dislike central services for communication. This isn't even a serious trust issue, I do believe that the developers of TextSecure are genuinely offering a great and secure text chat experience (ignoring that other solutions promise the same - Threema et al for example, but TextSecure comes with a lot more credibility and therefor trust). But I like to stay in control of my infrastructure. The xmpp server is the best fit - but the protocol and clients cause some issues and No One™ is using it, so the federation is a moot point.
Totally understand and respect your position. But one of the other great things about TextSecure is that although it may require a bit of work and you may not be interested, you could even run your own TextSecure server if you were so inclined because it's free software: https://github.com/WhisperSystems/TextSecure-Server
Unless something drastic changed (or I'm utterly misinformed) you could run your own server - and you'd split the network. The explanation was, as far as I recall, that there's no easy way to route things if all you got is a mobile number as an identifier (So .. on what server is that client? A JID has a host, a mobile number doesn't).
To reiterate: You probably could run your own server. In which case you and the 3-5 people you might convince to use that server would share some infrastructure under your control. You would not be able to send a message to the 6th friend that happens to use TextSecure, but _also_ needs to be on the authentic/real network to chat with his family.
Either that, or Google (or Microsoft or Apple) could use the same protocols as well for end-to-end encryption of voice and chats. And yes, hell could freeze over, too.
Is that an official CM build for Note 2? Either way, I think Whisperpush comes disabled CM ROMs anyway? At least it was on my unofficial CM ROM for a phone.
The first (A) is that TextSecure truncates SHA-2 hashes and, particularly, HMAC-SHA2 MACs. MAC truncation is extraordinarily common and is a design goal for most authenticated encryption schemes. So far as anyone knows, truncation of SHA-2 hashes and HMAC-SHA2 MACs is completely safe; that is, HMAC-SHA2 isn't somehow less safe when truncated than GCM or Poly1305.
The second (B) is that the authors believed TextSecure to have swapped some of the parameters for the HMAC algorithm. Moxie has asserted that this is a mistake by the paper authors, and that TextSecure uses HMAC conventionally.
The third (C, and most of the rest of the paper) is an identity misbinding attack. An identity misbinding attack happens when it becomes possible for Mallory to present Alice's public key to Bob instead of her own, and have Bob reply with a message encrypted to Mallory-seeming-Alice. Mallory can't decrypt the message, but because it's encrypted to a key Alice has, Alice might act based on the message contents. Identity misbinding problems are endemic to public-key cryptography. They are a real issue for protocols in which computers chat with each other and take action (like, authorizing an HTTP request) based on identities. They are less of an issue in chat protocols. Of particular importance, contextually: every other chat protocol has much, much worse key management problems.
Brian Smith says that this paper has value as part of a formal conversation about the security properties of TextSecure. I'm not qualified to evaluate that statement. I don't see anyone saying the paper has practical import for TextSecure or its users. TextSecure remains the best thing out there, I think.