<div dir="ltr"><div><div>Hi all,<br><br></div>Thanks for all the comments. Sorry I wasn't able to reply immediately. Please allow <br>me to summarize the comments. I see mainly the following questions.<br></div><div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">1. Quantum-safe authentication.<br></div><div class="gmail_extra">As Yawning has pointed out, <br><br>> I personally don't think that any of the PQ signature schemes are usable<br>
> for us right now, because the smallest key size for an algorithm that<br>
> isn't known to be broken is ~1 KiB (SPHINCS256), and we probably can't<br>
> afford to bloat our descriptors/micro-descriptors that much.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">This is also the reason we wanted to roll out QSH first and add the quantum-safe<br></div><div class="gmail_extra">signature schemes later. We have several good candidate for quantum-safe<br></div><div class="gmail_extra">encryption algorithms. But for signatures, they are not mature imho.<br><br></div><div class="gmail_extra">Another reason that we did not include authentication is due to the attack model.<br></div><div class="gmail_extra">As I have mentioned (but probably didn't explain very clearly) in previous email, we<br></div><div class="gmail_extra">are facing two types of attackers. Attacker type I, passive attacker at present, who <br></div><div class="gmail_extra">cannot break classical authentication nor encryption, record the data anyway, and <br></div><div class="gmail_extra">decrypt it when quantum computer become available in future. Attack type II, active<br></div><div class="gmail_extra">attacker who tries to attack the authentication while the communication is taking <br></div><div class="gmail_extra">place. This attack will be possible in future when quantum computer arrives. But for<br></div><div class="gmail_extra">now, they will not be successful. <br><br></div><div class="gmail_extra">As we believe that there does not exist a general purpose quantum computer at <br></div><div class="gmail_extra">present (and maybe several years away), we have time to deal with attacker type II.<br></div><div class="gmail_extra">But the attacker type I is the real threat at the present day. Our proposal is to address<br></div><div class="gmail_extra">this threat.<br><br></div><div class="gmail_extra">2. On NTRU vs NTRU-Prime vs R-LWE and others.<br></div><div class="gmail_extra">The QSH is modular designed to suite any quantum-safe encryption algorithm. So we<br></div><div class="gmail_extra">can chose any one we want for trail. And furthermore, we can also hybrid, say ECC, <br>NTRU and R-LWE, to give a bit more confidence in case one of the quantum-safe encryption<br></div><div class="gmail_extra">algorithm turns out to be not quantum safe, or broken.<br><br></div><div class="gmail_extra">That been said, we chose NTRU for several reasons. NTRU is more mature than R-LWE <br></div><div class="gmail_extra">from our point o view. NTRU has a full spec, a reference implementation, and is standardized<br></div><div class="gmail_extra">by several bodies; while for R-LWE, since it enables many interesting cryptographic primitives,<br></div><div class="gmail_extra">such as FHE, there has been many different parameter proposals, which leads to some kind <br></div><div class="gmail_extra">of confusion as to which one should reference to. <br></div><div class="gmail_extra"><br>> However, if we were to go the route of using NTRU, we'd likely want to instead<br>
> use Dan Bernstein's NTRU Prime parameters, in order to eliminate some of the<br>
> inherent algebraic structure of the ideal lattice which might possibly be<br>
> exploited. [0] [1]<br><br></div><div class="gmail_extra">As for NTRU-Prime, I am not aware there is a specific instantiation of this parameter sets, nor<br></div><div class="gmail_extra">any paper that considers the security of a specific parameter set. Also, this NTRU-Prime would<br></div><div class="gmail_extra">require some extensive scrutiny before we can use it. <br><br></div><div class="gmail_extra">We are happy to roll out any above encryption algorithm as you see fit. But our proposal is mainly<br></div><div class="gmail_extra">about the QSH approach. I think the best option for now is to buildin a QSH for Tor, with a flexible <br></div><div class="gmail_extra">API that allows us to switch between algorithms when fit. And for now use any quantum-safe<br></div><div class="gmail_extra">encryption algorithm that is ready to be used. After all, any QS encryption is better than nothing.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">3. License<br></div><div class="gmail_extra">I am sorry I am not familiar with the license. But my general feeling is that Security Innovation is<br></div><div class="gmail_extra">willing to let Tor to use NTRU for free. We just need to work out the suitable license to make this<br></div><div class="gmail_extra">happen.<br><br></div><div class="gmail_extra">4. Misc.<span class="im"><br>
</span>> Post-quantum forward-secrecy is what I've been using to describe this<br>
> property.<br></div><div class="gmail_extra"><br>We will use this terminology. Thanks.<br></div><div class="gmail_extra"><br>> As I recall, the product form parameter sets are extra encumbered.<br>> Apart from key/ciphertext size and a minor performance differential, is<br>
> there any reason to not use one of the X9.98 parameter sets (Eg:<br>> EES613EP1)<br></div><div class="gmail_extra"><br>Yes we can use non-product form polynomials, if everyone agrees on it.<br></div><div class="gmail_extra">Non-product form polynomials will make key generation and decryption <br></div><div class="gmail_extra">a bit slower, but those cost are on the client side. It has no impact on the <br></div><div class="gmail_extra">load of server side.<br><br><br></div><div class="gmail_extra">> * "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 security. Please see<br></div><div class="gmail_extra"><a href="https://eprint.iacr.org/2015/708.pdf">https://eprint.iacr.org/2015/708.pdf</a><br></div><div class="gmail_extra">for arguments of those security levels.<br><br>> I'm a little confused about what exactly is meant by "disaster resilience" here.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">We will remove "disaster resilience".</div><div class="gmail_extra"><br></div><div class="gmail_extra">Those are most comments I saw. Sorry if I missed some of your comments. Please let me know<br></div><div class="gmail_extra">if you have questions that I failed to answer.<br><br></div><div class="gmail_extra">Happy new year to everyone.<br><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Zhenfei<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 3, 2016 at 8:32 PM, Ryan Carboni <span dir="ltr"><<a href="mailto:ryacko@gmail.com" target="_blank">ryacko@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Wasn't there a transition period in migrating from RSA to ECC? <div><br></div><div>Maybe I'm just confused. Or you are confused. But I think it is best plan for a five or ten year transition period.</div></div>
<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></div></div></div>