Why did the NTRUencrypt team not maintain the NTRU1024 release in the NIST second-round competition?
Is this because of the speed performance or security performance or other things?
$\begingroup$
$\endgroup$
2
-
1$\begingroup$ Hello, Hassan. Someone made the same question on PQC forum and got this answer. Maybe you could read it then edit your question to highlight what is not clear there and which additional information you are seeking... $\endgroup$– Hilder Vitor Lima PereiraCommented May 31, 2019 at 7:39
-
$\begingroup$ Hello, Victor. Thanks for your response. $\endgroup$– user47167Commented Jun 1, 2019 at 15:06
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
This has been answered on the PQC forum. The question was asked by El Hassane Laaji:
Hello NTRU team
Can you say me, why you didn't keep the NTRUencrypt-1024 release, is it because of speed performance or security performance.
Best regards.
The reply came from John Schanck:
Thanks for your question. To clarify for others, the "NTRUencrypt-1024" parameter set was proposed in the first round NTRUEncrypt submission for use with the ss-ntru-pke and ss-ntru-kem schemes. I'll split your question into two parts:
Why didn't we recommend ss-ntru?
Why didn't we recommend an NTRU variant that uses Z[x]/(x^1024 + 1)?
Regarding ss-ntru:
At a fixed security level, NTRU and LWE schemes have a trade-off triangle between
the correctness of the decryption procedure,
the width of the coefficient distributions,
the compactness of public keys and ciphertexts.
The second round NTRU team wanted a compact scheme with a correct decryption procedure. The coefficient distribution used in ss-ntru is not compatible with that goal.
Regarding Z[x]/(x^1024 + 1):
It's not clear to us that there's a real need for an NTRU parameter set with such a large n. The largest n that we recommend is 821.
Best, John (on behalf of the NTRU team)
