[messaging] How secure is TextSecure?

[Nadim Kobeissi]

Wait, hold on! Scratch what I said, it appears that the paper is correct:
HKDF appears to be defined incorrectly in libaxolotl.

If you take a look at
`libaxolotl-android/java/src/main/java/org/whispersystems/libaxolotl/kdf/HKDF.java`,
specifically the `extract` method:


   - Line 52 appears to indeed be initializing an HMAC-SHA256 object using
   "salt" as the key.
   - Line 53 appears to indeed be MACing the key material as the message.

What was initially confusing was that the order of arguments being passed
to `deriveSecrets` (a pair of wrapper methods for `extract`) does appear to
be correct. But the actual `extract` method does things incorrectly it
seems.

Correct me if I'm mistaken, but the paper does indeed appear to be correct
in defining libaxolotl's HKDF. Perhaps this should be fixed?


On Tue, Apr 7, 2015 at 5:50 PM, Nadim Kobeissi <nadim at nadim.computer> wrote:

> 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/20150408/9695d39f/attachment.html>