[messaging] How secure is TextSecure?

Wed Apr 8 02:46:33 PDT 2015

The plot thickens:
It turns out that HKDF does in fact advocate using the salt as the HMAC
key. https://tools.ietf.org/html/rfc5869

So libaxolotl is indeed following the HKDF spec, it's the spec itself that
does things strangely. Confusing, but I guess there must be some kind of
explanation or proof. I'll keep looking.

On Wed, Apr 8, 2015 at 11:33 AM, Nadim Kobeissi <nadim at nadim.computer>
wrote:

> 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/7240187a/attachment.html>