<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<br />5. Aug 2016 15:07 by <a href="mailto:isis@torproject.org" target="_blank">isis@torproject.org</a>:<br /><br /><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><a target="_blank" href="mailto:lukep@tutanota.com">lukep@tutanota.com</a> transcribed 3.2K bytes:<blockquote>Great to see the community making progress with post-quantum handshakes.</blockquote><br />Hello,<br /><br />Thanks! :)<br /><blockquote>But I'm wondering what's going to happen with Proposals #269 and #270. #269<br />seems to allow any post-quantum algorithm to be used in the hybrid with<br />NTRUEncrypt and NewHope being specified as two options (presumably other<br />options like SIDH or Mceliece could also be used). #270 is more specific, a<br />hybrid of x25519 and NewHope. NewHope seems to be in the lead but do we want<br />to rule others - so a flexible proposal like #269 might be better. #269 and<br />#270 look as if they would not be compatible with each other so what's the<br />process for deciding between them?</blockquote><br />In the proposal-status document, [0] I described proposal #269 as "a<br />generalised protocol for composing X25519 key exchanges with post-quantum<br />ones" and proposal #270 as "a hybrid handshake based on the ntor handshake and<br />the NewHope post-quantum key exchange. Currently needs revision to specify<br />how this proposal depends upon prop#269."<br /><br />So it's not an either-or situation for proposals #269 and #270 — they are<br />entirely compatible and #269 is meant to provide modularity.</blockquote><p><br /></p><p>Thanks - that wasn't clear to me, although I can see that they are aiming in the same direction. I agree with the principle of separating out the handshake from the protocol for modularity, but I don't think that's quite been achieved and there's some overlap/confliction between the two of them. For example in how the hybrid secret key is computed.</p><p><br /></p><p>In #269, in the hybrid DH-KEM handshake it's computed as:</p><p>s0 := H(DH_MUL(A,x))</p><p>s1 := DH_MUL(Y,x)</p><p>s2 := KEM_DEC(C, esk)<br /></p><p>secret := s0 | s1 | s2</p><p><br /></p><p>On the other hand in #270, in the X25519-Newhope handshake it's computed as:</p><p>NTOR_KEY := NTOR_SHAREDA(x, X, Y, Z, ID, AUTH)</p><p>NEWHOPE_KEY := NEWHOPE_SHAREDA(M, a)</p><p>sk := SHAKE-256(NTOR_KEY || NEWHOPE_KEY)<br /></p><br />As it stands, secret and sk are computed in a contradictory manner; these could be reconciled so they are the same, but if you are trying to write modular proposals the handshake algorithm should only be specified in one document. I think the method of computing the secret should be specified in #270 (only), and the protocol (depending on a call to the DH-KEM key exchange) should be specified in #269.<br /><br /><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><blockquote>Also see <a target="_blank" href="https://eprint.iacr.org/2016/717.pdf">https://eprint.iacr.org/2016/717.pdf</a>, a comparison of attacks on<br />NTRU. It doesn't break NTRU but it does break (some versions of) YASHE which<br />is a FHE scheme based on NTRUEncrypt. In the conclusion it recommends<br />transforming NTRU-like algorithms into ring-LWE like algorithms, and<br />dismissing the former since they are known to be weaker. I still think a<br />flexible protocol rather than all eggs in the NewHope basket is a Good<br />Thing.</blockquote><br />I'm not sure I follow the reasoning here. What I hear you saying is: "Some<br />really weird schemes which use NTRU in an unsafe way are broken, ergo we<br />should remain open to schemes other than NewHope." That still doesn't make<br />sense to me.</blockquote><p><br /></p><p>It was two separate statements really. Having flexibility on choice of algorithm is a good idea. Some weird scheme which is based on NTRU has been broken. If I had a point, it was "new research can come to light which casts doubt on certain choices of algorithms, so it's better to have a protocol that doesn't tie you to one algorithm". Sorry for the confusion. <br /></p><p><br /></p><p><br /></p><p>-- lukep</p><p><br /></p> </body>
</html>