<div dir="ltr">Wait, hold on! Scratch what I said, it appears that the paper is correct: HKDF appears to be defined incorrectly in libaxolotl.<div><br></div><div>If you take a look at `libaxolotl-android/java/src/main/java/org/whispersystems/libaxolotl/kdf/HKDF.java`, specifically the `extract` method:<br><div><br></div><div><ul><li>Line 52 appears to indeed be initializing an HMAC-SHA256 object using "salt" as the key.</li><li>Line 53 appears to indeed be MACing the key material as the message.</li></ul><div>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.</div><div><br></div><div>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?</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 7, 2015 at 5:50 PM, Nadim Kobeissi <span dir="ltr"><<a href="mailto:nadim@nadim.computer" target="_blank">nadim@nadim.computer</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>On Sat, Nov 1, 2014 at 8:24 AM, Moxie Marlinspike <span dir="ltr"><<a href="mailto:moxie@thoughtcrime.org" target="_blank">moxie@thoughtcrime.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
<br>
On 10/31/2014 09:56 PM, David Leon Gil wrote:<br>
> -- They present an unknown key-share attack on TextSecure; this is<br>
> rather serious, to say the least.<br>
<br>
</span>I'm not so sure. One party claiming another's fingerprint is a minor<br>
but general issue with fingerprints almost everywhere they are used. It<br>
affects SSH, OTR, PGP, etc.<br>
<br>
They describe a scenario where Bart wants to trick his friend Milhouse.<br>
Bart knows that Milhouse is going to invite him to his party. So Bart<br>
changes his own published public identity key to Nelson's public<br>
identity key. Then when Milhouse sends the invite to Bart, Bart can<br>
take the message (which he can't decrypt, but assumes is the invite) and<br>
forward it to Nelson (while somehow spoofing Milhouse's source address).<br>
Now Nelson thinks he was invited to the party (Bart hopes the message<br>
content doesn't read: "Hey Bart,..."). The attack would require that the<br>
server is colluding with Bart.<br>
<br>
The paper recommends hashing addresses into the MAC. We were actually<br>
the ones to suggest that to them, but there are philosophical limits on<br>
how effective that can be. Bart could claim that his number changed (to<br>
Nelson's number) at the same time that he claims his identity key has<br>
changed.<br>
<br>
For that matter, if I meet you in person for the first time, you can<br>
even claim someone else's name as your own, in addition to their phone<br>
number and fingerprint.<br>
<br>
So including logical addresses in the MAC helps with some cases, but one<br>
could always construct cases where it doesn't.<br>
<br>
The two-phase QR code thing they propose doesn't work for offline<br>
verification (people putting fingerprints on business cards, email sigs,<br>
etc) or remote verification (people reading fingerprints over the<br>
phone). It also feels pretty cumbersome. Right now, preserving those<br>
types of verification feels more valuable to us than compromising on<br>
them to stop a somewhat esoteric UKS.<br>
<span><br>
> Rather puzzling, however: 1. They<br>
> claim that HMAC(key=constant, message=secret) is not provably a PRF.<br>
<br>
</span>What's more puzzling is that we're not doing that. We do<br>
HMAC(key=secret, message=constant). It could be that I'm missing<br>
something. I'll email them and get them to show me the code, but I<br>
suspect they made a mistake in their analysis.<br></blockquote><div><br></div></div></div><div>Yup. The implementation code does indeed indicate that the paper got that aspect of the ratchet incorrectly.</div><div><br></div><div>For any potential future person who happens to benefit from this line of inquiry:</div><div><a href="https://github.com/WhisperSystems/libaxolotl-android/blob/0f7d0db039a60e8d1a9fb8748ed9262e0ffc7a58/java/src/main/java/org/whispersystems/libaxolotl/ratchet/ChainKey.java" target="_blank">https://github.com/WhisperSystems/libaxolotl-android/blob/0f7d0db039a60e8d1a9fb8748ed9262e0ffc7a58/java/src/main/java/org/whispersystems/libaxolotl/ratchet/ChainKey.java</a><br></div><div><a href="https://github.com/WhisperSystems/libaxolotl-android/blob/0f7d0db039a60e8d1a9fb8748ed9262e0ffc7a58/java/src/main/java/org/whispersystems/libaxolotl/ratchet/RootKey.java" target="_blank">https://github.com/WhisperSystems/libaxolotl-android/blob/0f7d0db039a60e8d1a9fb8748ed9262e0ffc7a58/java/src/main/java/org/whispersystems/libaxolotl/ratchet/RootKey.java</a><br></div><div><a href="https://github.com/WhisperSystems/libaxolotl-android/blob/0f7d0db039a60e8d1a9fb8748ed9262e0ffc7a58/java/src/main/java/org/whispersystems/libaxolotl/kdf/HKDF.java" target="_blank">https://github.com/WhisperSystems/libaxolotl-android/blob/0f7d0db039a60e8d1a9fb8748ed9262e0ffc7a58/java/src/main/java/org/whispersystems/libaxolotl/kdf/HKDF.java</a><span><font color="#888888"><br></font></span></div><span><font color="#888888"><div><br></div><div>Nadim</div></font></span><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><br>
> 2. They also claim that the security of truncated<br>
> SHA2-256, as used in TextSecure tags, is unknown.<br>
<br>
</span>Since this is extremely common practice, is approved by NIST, and is<br>
approved in the HMAC RFC, I think we're in good shape.<br>
<span><br>
> More concerning re<br>
> tags: TextSecure is only using an 8 byte tag. 64-bit authenticity is<br>
> plainly insufficient.<br>
<br>
</span>I dunno. Sure 16 or 32 bytes would be better, but we're dealing with a<br>
world of really extreme size constraints where another 8 bytes is a<br>
*lot*. In the context of how this tag is specifically used for<br>
TextSecure messages (where there is no oracle), I'd like to hear more<br>
about where you see a practical attack.<br>
<span><font color="#888888"><br>
- moxie<br>
<br>
--<br>
<a href="http://www.thoughtcrime.org" target="_blank">http://www.thoughtcrime.org</a><br>
</font></span><div><div>_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br>
</div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>