Other NTRUPrime systems?

Choice of performance requirement. Consider the problem of fitting a client’s public key into a single Internet packet. This allows a server to immediately set up a cryptographic session, encapsulating a session key in its response packet, without having to buffer any data; such buffers are a traditional target for denial-of-service attacks.

IPv6 guarantees that a 1280-byte packet will be transmitted successfully (while measure- ments such as [132] and [131] indicate that slightly larger packets often encounter failures), so it is natural to set 1280 bytes as a packet-size limit. This does not mean that the key-size limit should be as large as 1280 bytes. Part of the space in a packet is consumed by overhead, and the amount of overhead depends on other protocol details. For example, a minimal IPv6 header consumes 40 bytes (as opposed to 20 bytes for IPv4); a UDP header consumes 8 bytes; protocol designers often include 32 bytes for an ECC key; protocol designers often include a connection identifier; etc. Leaving some room below 1280 bytes provides flexibility for the protocol designer.

We rank (p, q, w) by estimated security, subject to requiring 0.25 ≤ w/p ≤ 0.5 and
p log256 q ≤ 1280. The top three results are the following:
• (823, 4513, 282), with w/p ≈ 0.34 and p log256 q ≈ 1248.89; 31 bytes of flexibility
(assuming space-optimal encoding into bytes).
• (787, 4243, 265), with w/p ≈ 0.34 and p log256 q ≈ 1185.50; 94 bytes of flexibility.
• (761, 4591, 286), with w/p ≈ 0.38 and p log256 q ≈ 1157.16; 122 bytes of flexibility.

The ordering of these three results is consistent across all 13 security estimates in our com- putations, except that the second and third results are exchanged in one ranking. Note that there is a more important impact of the allowed range of weight fractions: the top two results would have disappeared if we had required w ≥ b3p/8c, as in [122]. We have selected the (761, 4591, 286) parameter set, with 122 bytes of flexibility. In our round-1 submission we used some of this flexibility to accommodate a somewhat less space-efficient encoding of public keys; we are now using a more space-efficient encoding

Most of this is from here https://ntruprime.cr.yp.to/nist/ntruprime-20201007.pdf

It seems that 761 is acceptable for tls but really for future proof, we want kem/sntrup1013 paired with aes 256

I think theoretically I saw aes 256 may be reduced to 128 bit security post quantum

But I think we theoretically want the KEM to be more secure

just a thought 761 for tls 1013 for KEM , AES for Core. if that makes any sense.

NTRU Prime. Quantitatively, the smallest number listed in Table 2 for (761, 4591) is 2139 quantum “operations”, while a Grover attack against AES-256 would use just 2128 quantum “operations”.

To summarize, the NTRU Prime public key here must fit into 1280 − 226 = 1054 bytes, and below this we want to leave extra space for flexibility—for example, 48 bytes to accommodate IPv6+UDP header information. Ranking parameters with 0.25 ≤ w/p ≤ 0.5 and p log256 q ≤ 1054 consistently produces the following top two results: • (653, 4621, 288), with w/p ≈ 0.44 and p log256 q ≈ 993.702; 60 bytes of flexibility. • (647, 3559, 222), with w/p ≈ 0.34 and p log256 q ≈ 954.103; 99 bytes of flexibility. We select (653, 4621, 288).

Estimates that account for hybrid attacks and for the real cost of memory consistently rank the 857 parameter set higher. We thus select the (857, 5167, 322) parameter set. The same parameter set was also noted by Schanck in [122]

8 Expected strength (2.B.4) for each parameter set

Disclaimer this is curation of Dans paper/ proposal Just trying to pass some of the better info out of it for making a decision.

companyzero / sntrup4591761

Other NTRUPrime systems? #4

8 Expected strength (2.B.4) for each parameter set