[messaging] How secure is TextSecure?

[Moxie Marlinspike]

On 10/31/2014 09:56 PM, David Leon Gil wrote:
> -- They present an unknown key-share attack on TextSecure; this is
> rather serious, to say the least. 

I'm not so sure.  One party claiming another's fingerprint is a minor
but general issue with fingerprints almost everywhere they are used.  It
affects SSH, OTR, PGP, etc.

They describe a scenario where Bart wants to trick his friend Milhouse.
 Bart knows that Milhouse is going to invite him to his party.  So Bart
changes his own published public identity key to Nelson's public
identity key.  Then when Milhouse sends the invite to Bart, Bart can
take the message (which he can't decrypt, but assumes is the invite) and
forward it to Nelson (while somehow spoofing Milhouse's source address).
 Now Nelson thinks he was invited to the party (Bart hopes the message
content doesn't read: "Hey Bart,..."). The attack would require that the
server is colluding with Bart.

The paper recommends hashing addresses into the MAC.  We were actually
the ones to suggest that to them, but there are philosophical limits on
how effective that can be.  Bart could claim that his number changed (to
Nelson's number) at the same time that he claims his identity key has
changed.

For that matter, if I meet you in person for the first time, you can
even claim someone else's name as your own, in addition to their phone
number and fingerprint.

So including logical addresses in the MAC helps with some cases, but one
could always construct cases where it doesn't.

The two-phase QR code thing they propose doesn't work for offline
verification (people putting fingerprints on business cards, email sigs,
etc) or remote verification (people reading fingerprints over the
phone). It also feels pretty cumbersome.  Right now, preserving those
types of verification feels more valuable to us than compromising on
them to stop a somewhat esoteric UKS.

> Rather puzzling, however: 1. They
> claim that HMAC(key=constant, message=secret) is not provably a PRF.

What's more puzzling is that we're not doing that.  We do
HMAC(key=secret, message=constant).  It could be that I'm missing
something.  I'll email them and get them to show me the code, but I
suspect they made a mistake in their analysis.

> 2. They also claim that the security of truncated
> SHA2-256, as used in TextSecure tags, is unknown.

Since this is extremely common practice, is approved by NIST, and is
approved in the HMAC RFC, I think we're in good shape.

> More concerning re
> tags: TextSecure is only using an 8 byte tag. 64-bit authenticity is
> plainly insufficient.

I dunno.  Sure 16 or 32 bytes would be better, but we're dealing with a
world of really extreme size constraints where another 8 bytes is a
*lot*.  In the context of how this tag is specifically used for
TextSecure messages (where there is no oracle), I'd like to hear more
about where you see a practical attack.

- moxie

-- 
http://www.thoughtcrime.org