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?
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.Sign up to join this community
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.
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)?
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)