<div dir="ltr"><div><div><div><div>Thanks Yawning.<br></div><div><br>> Agreed.  I like the QSH design, though I still want to use FIPS 202<br>
> (SHA-3/SHAKE) instead of HMAC-SHA256/HKDF-SHA256, due to "Since we're<br>
> changing things anyway, we may as well future proof here too".<br><br></div>Yes. Will put that in the request too. Sorry missed this comment in previous email.<br><br>> Client side for Tor is somewhat deceptive because Hidden Services act<br>
> as the client when connecting to the Rdv point, so we do care about<br>> performance there too.  I fully expect that the gains that we will get<br>
> from separate work due to improved threading will pay for the CPU cost<br>
> increases here, but I'll need to do some benchmarking to be certain.<br><br></div>Thanks. I didn't know that. <br><br></div>Cheers,<br></div>Zhenfei<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 4, 2016 at 1:26 PM, Yawning Angel <span dir="ltr"><<a href="mailto:yawning@schwanenlied.me" target="_blank">yawning@schwanenlied.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(Note: Snipping liberally for brevity)<br>
<span class=""><br>
On Mon, 4 Jan 2016 11:56:54 -0500<br>
Zhenfei Zhang <<a href="mailto:zzhang@securityinnovation.com">zzhang@securityinnovation.com</a>> wrote:<br>
> 2. On NTRU vs NTRU-Prime vs R-LWE and others.<br>
> The QSH is modular designed to suite any quantum-safe encryption<br>
> algorithm. So we can chose any one we want for trail. And<br>
> furthermore, we can also hybrid, say ECC, NTRU and R-LWE, to give a<br>
> bit more confidence in case one of the quantum-safe encryption<br>
> algorithm turns out to be not quantum safe, or broken.<br>
<br>
</span>Hybridizing all 3 probably will get somewhat expensive (though not<br>
prohibitively so), nickm and I have branches to thread the client side<br>
circuit build crypto which will help mask the performance penalty of<br>
this proposal in general (not yet merged, shouldn't require changes to<br>
your branch).<br>
<span class=""><br>
> That been said, we chose NTRU for several reasons. NTRU is more<br>
> mature than R-LWE from our point o view. NTRU has a full spec, a<br>
> reference implementation, and is standardized by several bodies;<br>
> while for R-LWE, since it enables many interesting cryptographic<br>
> primitives, such as FHE, there has been many different parameter<br>
> proposals, which leads to some kind of confusion as to which one<br>
> should reference to.<br>
<br>
</span>At the current time, if I had to pick one, I'd use the newhope variant<br>
of Peikert's KEM scheme (And in fact was going to amend the proposal<br>
to specify that as the Ring-LWE primitive).<br>
<br>
The BCNS proposal has gotten slightly more scrutiny, but it's slower,<br>
has larger keys, and provides a lower security level than newhope.<br>
<span class=""><br>
> We are happy to roll out any above encryption algorithm as you see<br>
> fit. But our proposal is mainly about the QSH approach. I think the<br>
> best option for now is to buildin a QSH for Tor, with a flexible<br>
> API that allows us to switch between algorithms when fit. And for now<br>
> use any quantum-safe encryption algorithm that is ready to be used.<br>
> After all, any QS encryption is better than nothing.<br>
<br>
</span>Agreed.  I like the QSH design, though I still want to use FIPS 202<br>
(SHA-3/SHAKE) instead of HMAC-SHA256/HKDF-SHA256, due to "Since we're<br>
changing things anyway, we may as well future proof here too".<br>
<span class=""><br>
> 3. License<br>
> I am sorry I am not familiar with the license. But my general feeling<br>
> is that Security Innovation is willing to let Tor to use NTRU for<br>
> free. We just need to work out the suitable license to make this<br>
> happen.<br>
<br>
</span>I'm glad to hear that.  My main concern here is that if, say Debian<br>
Legal thinks that the existing FOSS patent wavier is insufficient to<br>
allow NTRU to be included in Debian packages till 2017, this will<br>
significantly hamper the relay side uptake of the safer primitives due<br>
to the Debian monoculture on our relays.<br>
<br>
I can do the Ring-LWE work, since the QSH primitive is modular so that<br>
there will be options for people that have more stringent<br>
license/patent policies than we do.<br>
<br>
If I were to prioritize handshake selection, I would lean towards<br>
NTRU + Ring-LWE, over NTRU, over Ring-LWE based on what the<br>
peer supports.<br>
<span class=""><br>
> > As I recall, the product form parameter sets are extra encumbered.<br>
> > Apart from key/ciphertext size and a minor performance<br>
> > differential, is there any reason to not use one of the X9.98<br>
> > parameter sets (Eg: EES613EP1)<br>
><br>
> Yes we can use non-product form polynomials, if everyone agrees on it.<br>
> Non-product form polynomials will make key generation and decryption<br>
> a bit slower, but those cost are on the client side. It has no impact<br>
> on the load of server side.<br>
<br>
</span>Client side for Tor is somewhat deceptive because Hidden Services act<br>
as the client when connecting to the Rdv point, so we do care about<br>
performance there too.  I fully expect that the gains that we will get<br>
from separate work due to improved threading will pay for the CPU cost<br>
increases here, but I'll need to do some benchmarking to be certain.<br>
<span class=""><br>
> > * "For 128 bits quantum security, use NTRU_EESS743EP1." should be<br>
> >   "For 256 bits" (Section 2.3).<br>
><br>
> NTRU_EESS743EP1 provides 256 classical security and 128 bits quantum<br>
> security. Please see<br>
> <a href="https://eprint.iacr.org/2015/708.pdf" rel="noreferrer" target="_blank">https://eprint.iacr.org/2015/708.pdf</a><br>
> for arguments of those security levels.<br>
<br>
</span>Ah gotcha, I haven't seen that paper and I was going off the initial<br>
estimates, thanks for the clarification.<br>
<br>
Regards,<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Yawning Angel<br>
</font></span><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>