<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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 class="">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></blockquote><div><br></div><div>I think Moxie has a good point here.</div><div><br></div><div>I think the thing to take away from this paper is that the TextSecure protocol might be close to being something that can be formally proved, and that it is worth considering the role of formal proofs in the design and development of TextSecure. There may be things that can be changed in the to make such proofs of security easier or clearer. Alternatively, there may be other ways of approaching a security proof for TextSecure that do not depend on changing the protocol. The authors seem to have chosen to change the protocol for their proof, probably because they couldn't figure out how to make a proof for the protocol as it is. I think it would be cool if people could build upon their work to create a proof for the protocol without changes.</div><div><br></div><div>More below.</div><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">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></blockquote><div><br></div><div>I think that is a reasonable. Still, it may be useful to investigate changes to the protocol that works better than their suggestion, and which still affords a formal proof.</div><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 class="">> 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></blockquote><div><br></div><div>I think it is important to point out that Moxie's statement doesn't contradict the authors' statement. Here is the authors' full statement:</div><div><br></div><div><div> Surprisingly, TEXTSECURE does not transmit the complete</div><div> output of HMACSHA256. The message tag in Figures 2 and</div><div> 3 does only represent the first 64 bit of the 256 bit MAC.</div><div> Upon request, TEXTSECURE’s developers stated that this</div><div> just happens to reduce message size. However, SHA256</div><div> has been designed to achieve its security goals with an</div><div> output length of a full 256 bit. While Biryukov et al. [19]</div><div> analysed the security of reduced-round SHA256, to the best</div><div> of our knowledge, the security of a reduced-length SHA256</div><div> has not been investigated, yet. However according to</div><div> NIST [20, chapter 5.5], a MAC length of 80 bit is</div><div> recommended when a MAC is used for key confirmation,</div><div> which is the case in TEXTSECURE (at least) in the first</div><div> message of a new session.</div></div><div><br></div><div>It is fair for them to point out that they couldn't find a proof that truncating HMAC-SHA256 is secure. In fact, they *have* to say that in their paper, because their attempted proof assumes it, but they offer no proof. Ideally, they would just cite an already-published formal proof, or write a proof of their own. Perhaps somebody could suggest one to them. At the same time, they didn't say that TextSecure is terrible because it truncates the HMAC. In fact, they say the opposite: TextSecure seems to be doing something OK because it is following NIST's recommendations. (Note that I don't follow how truncating the HMAC to 64 bits is in line with NIST's recommendations for at least 80 bits, but I'm probably overlooking or misunderstanding something.)</div><div><br></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 class="">> 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></blockquote><div><br></div><div><div>I think that when this discussion is over, it would be useful to update the TextSecure protocol documentation with an explanation as to why the HMAC is truncated to 8 bytes (as opposed to 16 bytes as one might expect by default, or 4 bytes or 6 bytes), and why it is felt that the truncation is secure, because it isn't clearly documented now.</div></div><div><br></div><div>I assume the authors think it would be good for TextSecure to have a formal proof, and I agree. Do others?</div><div><br></div><div>Also, one takeaway from the paper that I had is that the TextSecure protocol seems good overall. I think that's pretty positive feedback.</div><div><br></div><div>Cheers,</div><div>Brian</div><div><br></div></div></div></div>