Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

There are three concerns raised in this paper.

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.

Ehh, seems they were talking about different HMAC parameters and I was thinking about the HKDF...sorry (see the moderncrypto discussion for more).

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

You don't need to rely on the assertions of the authors; you can find the source at https://github.com/whispersystems/textsecure .

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

Or am I missing something?

Could they be use BLAKE2 instead, which seems to have a "simpler design" than HMAC-SHA1/2:

https://blake2.net/

I believe miniLock uses it, too.

What exactly would that improve in the security of TextSecure?

Reply on news.ycombinator.com