<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hello list,<br><br></div>We had a very constructive discussion on this proposal last Thursday. <br>I have updated the feature request based on the feedback from the discussion.<br></div><div>We also like to thank Roger for grammar fixes on the proposal.<br></div><div><br></div><div>The diff file is available at:<br><a href="https://github.com/zhenfeizhang/ntru-tor/commit/dc48c2065d1772c5497cd6ad900b54f6fbd24cef">https://github.com/zhenfeizhang/ntru-tor/commit/dc48c2065d1772c5497cd6ad900b54f6fbd24cef</a><br><br><br></div>Major tech updates are:<br></div>1. Use SHA3 and SHAKE instead of HMAC_SHA3<br></div><br>2. In previous proposal, when server sends back the message, it sends a ciphertext<br><span class="">C           = ENCRYPT( P | B, QSPK), and its one-time ECC public key Y = e^y;<br></span></div><span class="">where P is the secret that server chose, B is servers long term public key.<br><br></span></div><span class="">In this new version, we also include servers short term public key in the plaintext, i.e.,</span><br><span class=""><span class="">C           = ENCRYPT( P | B | Y, QSPK)<br></span></span></div><span class=""><span class="">and Y is no longer send to the client separately. The client will need to decrypt<br></span></span></div><span class=""><span class="">C first and retrieve Y from the message. Y is not revealed to any one other than the <br></span></span></div><div><span class=""><span class="">client.<br></span></span></div><div><span class=""><span class=""><br></span></span></div><div><span class=""><span class="">This is proposed by Nick. It was also suggested to us by Aniket Kate. We thank Nick <br>and Aniket for the suggestion. This modification will save 32 bytes of traffic as Y is no <br>longer transmitted. Also since Y is now encrypted it will be a little harder for the attacker <br>to attack the 25519 keys.<br></span></span></div><div><span class=""><span class=""><br></span></span></div><span class=""><span class="">3. Choosing algorithms and parameters for the protocol.<br></span></span></div><div><span class=""><span class="">We have identified NTRUEncrypt and R-LWE as two candidates for this protocol.<br></span></span></div><div><span class=""><span class="">We have agreed to use NTRUEncrypt for now, in the meantime, keep the option open<br></span></span></div><div><span class=""><span class="">for "newesthope" version of R-LWE type key exchange when it becomes available. Also,<br>for NTRUEncrypt we will be using parameters sets with SHA3, to align with Tor specs. <br>I have modified the feature request to reflect this change. <br><br>Also in the discussion we were talking about the possibility of using non-product form <br>polynomial version of NTRUEncrypt, as this version will become patent free by Aug 2017,<br></span></span></div><div><span class=""><span class="">while the patent for product form will last for another 4 years. The main concern is that <br>Debian will not allow patented software in the package.  However, through our discussion,<br>it turns out that we may be able to include this proposal in the next one of two release of <br>Tor. From this point of view, both patent (basic NTRU patent, till 2017 and product form <br>patent, till 2021) are going to be an issue if Debian does not agree with SI's patent statement.<br></span></span></div><div><span class=""><span class="">So does it make sense to keep the product form polynomials as they enables roughly 3<br></span></span></div><div><span class=""><span class="">times faster operations on both client side and server side?<br><br></span></span><br><span class=""><span class="">Thanks for your time, and please let us know if you have any further comments/suggestions.<br><br></span></span></div><div><span class=""><span class="">Best regards,<br></span></span></div><div><span class=""><span class="">Zhenfei<br></span></span></div><div><span class=""><span class=""><br></span></span></div><span class=""><span class=""><br></span></span></div>