<div dir="ltr">Hi Peter,<div><br></div><div><span style="font-size:12.8px">> That's great news! Any thoughts on the license? Can you place it into</span><br style="font-size:12.8px"><span style="font-size:12.8px">> public domain?</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I am not 100% sure but I think it will be the same as the current NTRU </span><span style="font-size:12.8px">implementation.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> Did the attachment get lost?</span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Sorry. Here are the data extracted from our paper. The final version will be ready in a </span></div><div><span style="font-size:12.8px">couple of days.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The data are based on ntru-443 with CCA-2. By moving to CPA, we may </span><span style="font-size:12.8px">be able to </span></div><div><span style="font-size:12.8px">save say 30% of computation. The ntru-743 is roughly 2.5x slower than </span><span style="font-size:12.8px">ntru-443.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Cheers,</span></div><div><span style="font-size:12.8px">Zhenfei</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 26, 2016 at 1:35 AM, Peter Schwabe <span dir="ltr"><<a href="mailto:peter@cryptojedi.org" target="_blank">peter@cryptojedi.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Zhenfei Zhang <<a href="mailto:zzhang@securityinnovation.com">zzhang@securityinnovation.com</a>> wrote:<br>
> Hi Peter,<br>
<br>
Hi Zhenfei, hi all,<br>
<span class=""><br>
> We are working on a constant-time implementation of NTRU. We expect to<br>
> release the source code this summer.<br>
<br>
</span>That's great news! Any thoughts on the license? Can you place it into<br>
public domain?<br>
<span class=""><br>
> However, as far as I know, timing attacks are much more powerful<br>
> against encryption algorithm (that uses long-lived key for multiple<br>
> times), rather than KEMs (use ephemeral keys).  Our proposal treats<br>
> NTRU as a KEM so I think the timing attack is not so useful.<br>
<br>
</span>It's tricky; I agree that if you get only a single timing trace with the<br>
same key, it will be much harder to get useful information about the<br>
key than in a public-key encryption (or signature) setting where the<br>
private key is used many times. Then again, I also think that it will be<br>
very hard to prove that it's impossible to extract useful information<br>
about keys from timing on any platform.<br>
Maybe more importantly, Tor does not only have to be concerned about<br>
leaking the key, but also leaking de-anonymizing information. That's why<br>
Isis and I sat down and wrote a constant-time version of the sampling of<br>
the public polynomial in NewHope.<br>
My general take on this is that it's much easier to write constant-time<br>
code than to deal with the fallout caused by software that is vulnerable<br>
to timing attacks.<br>
<span class=""><br>
> Please see the attached for some benchmark results.<br>
<br>
</span>Did the attachment get lost?<br>
<span class=""><br>
> We are working on the camera-ready version of the paper. The final<br>
> version should be out soon.  Also note that we are using an IND-CCA-2<br>
> secure version of NTRU. The performance can be further improved by<br>
> switching to the IND-CPA secure version. IND-CPA is enough to provide<br>
> channel security, provide that the ciphertext is accepted for only<br>
> once for a given key. (This may open doors to some DoS attack.) As far<br>
> as I can tell, the NewHope and NTRU-prime all uses CPA secure<br>
> encryption algorithms.<br>
<br>
</span>Definitely true for NewHope.<br>
<br>
<br>
Here's what my answers would be to your questions:<br>
<span class=""><br>
> It would be nice to have a final decision on<br>
> a. shall we use non-production form<br>
<br>
</span>Would be interesting to see benchmarks of both.<br>
<span class=""><br>
> b. shall we remove the IND-CCA-2 feature<br>
<br>
</span>Again, it would be interesting in a larger context to have benchmarks of<br>
both; the Tor handshake should be fine with IND-CPA.<br>
<span class=""><br>
> c. shall we use ntru-743/887 to build a sufficiently large margin just like<br>
> NTRUprime<br>
<br>
</span>Definitely. As I wrote in my previous mail, in NewHope we went for a<br>
much larger margin than NTRUprime did; I would probably feel better with<br>
887, but for long-term security (and this is what the whole thing is<br>
about), 743 is a must-have.<br>
<br>
<br>
Cheers,<br>
<br>
Peter<br>
<br>_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
<br></blockquote></div><br></div></div>