<div dir="ltr">Hi all,<div><br></div><div>> <span style="font-size:12.8px">3. The only implementation that mitigates decryption failures completely, killing information leaks to adversaries.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This is clearly a nice-to-have feature, but it comes with a tradeoff. To remove decryption failures you need to increase the parameter q, but this affects size (and so performance) in two ways: first, the key and ciphertext are arrays of integers mod q, so obviously increasing log_2(q) increases key and ciphertext size; but second, increasing q makes lattice reduction attacks more effective, so it means that you need to increase the dimension parameter N as well to get the same level of lattice security. Conversely, it's not difficult to calculate upper bounds on decryption failure probabilities, so it's straightforward to find a q that gives less than 2^-k chance of a decryption failure. There's no particular need for a decryption failure probability that's less than the security of the other parts of the cryptosystem.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Just wanted to explain why the standardized NTRUEncrypt parameter sets (from <a href="https://github.com/NTRUOpenSourceProject/ntru-crypto">https://github.com/NTRUOpenSourceProject/ntru-crypto</a>) are chosen the way they are, i.e. to have nonzero decryption failure probability. We could have chosen larger q and N but didn't think the tradeoff is worth it. Obviously the other point of view is legitimate too.</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"><br></span></div><div><span style="font-size:12.8px">William</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><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><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 9:51 PM,  <span dir="ltr"><<a href="mailto:bancfc@openmailbox.org" target="_blank">bancfc@openmailbox.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Some great developments in lattice-based crypto. DJB just released a paper on NTRU Prime:<br>
<br>
<br>
1. Competitively fast compared to the leading lattice-based cryptosystems including New Hope.<br>
<br>
2. Safer implementation of NTRU that avoids vulnerable ring structures and runs in constant-time.<br>
<br>
3. The only implemntation that mitigates decryption failures completely, killing information leaks to adversaries.<br>
<br>
4. Includes some handy advice for "transitional cryptography" - mixing and matching classical signature schemes with PQ public-keys.<br>
<br>
<br>
<a href="https://ntruprime.cr.yp.to/ntruprime-20160511.pdf" rel="noreferrer" target="_blank">https://ntruprime.cr.yp.to/ntruprime-20160511.pdf</a><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org" target="_blank">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>
</div></div></blockquote></div><br></div>