[messaging] How secure is TextSecure?

[Nadim Kobeissi]

On Sat, Nov 1, 2014 at 8:24 AM, Moxie Marlinspike <moxie at thoughtcrime.org>
wrote:

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

Yup. The implementation code does indeed indicate that the paper got that
aspect of the ratchet incorrectly.

For any potential future person who happens to benefit from this line of
inquiry:
https://github.com/WhisperSystems/libaxolotl-android/blob/0f7d0db039a60e8d1a9fb8748ed9262e0ffc7a58/java/src/main/java/org/whispersystems/libaxolotl/ratchet/ChainKey.java
https://github.com/WhisperSystems/libaxolotl-android/blob/0f7d0db039a60e8d1a9fb8748ed9262e0ffc7a58/java/src/main/java/org/whispersystems/libaxolotl/ratchet/RootKey.java
https://github.com/WhisperSystems/libaxolotl-android/blob/0f7d0db039a60e8d1a9fb8748ed9262e0ffc7a58/java/src/main/java/org/whispersystems/libaxolotl/kdf/HKDF.java

Nadim


>
> > 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
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150407/78fc8160/attachment.html>