Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Other NTRUPrime systems? #4

Open
1 of 8 tasks
DonaldTsang opened this issue May 13, 2019 · 1 comment
Open
1 of 8 tasks

Other NTRUPrime systems? #4

DonaldTsang opened this issue May 13, 2019 · 1 comment

Comments

@DonaldTsang
Copy link

  • sntrup653
  • ntrulpr653
  • sntrup761
  • sntrup4591761
  • ntrulpr761
  • ntrulpr4591761
  • sntrup857
  • ntrulpr857
@syonfox
Copy link

syonfox commented Mar 28, 2023

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

image

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

8 Expected strength (2.B.4) for each parameter set 8.1 Parameter set kem/sntrup653 Category 1, as per bulletproofing strategy #1. Bulletproofing strategy #2 would also say Category 1. 8.2 Parameter set kem/sntrup761 Category 2, as per bulletproofing strategy #1. Bulletproofing strategy #2 would also say Category 2. 83 8.3 Parameter set kem/sntrup857 Category 3, as per bulletproofing strategy #1. Bulletproofing strategy #2 would instead say Category 2. 8.4 Parameter set kem/sntrup953 Category 4, as per bulletproofing strategy #1. Bulletproofing strategy #2 would instead say Category 3. 8.5 Parameter set kem/sntrup1013 Category 4, as per bulletproofing strategy #1. Bulletproofing strategy #2 would also say Category 4. 8.6 Parameter set kem/sntrup1277 Category 5, as per bulletproofing strategy #1. Bulletproofing strategy #2 would also say Category 5. 8.7 Parameter set kem/ntrulpr653 Category 1, as per bulletproofing strategy #1. Bulletproofing strategy #2 would also say Category 1. 8.8 Parameter set kem/ntrulpr761 Category 2, as per bulletproofing strategy #1. Bulletproofing strategy #2 would also say Category 2. 8.9 Parameter set kem/ntrulpr857 Category 3, as per bulletproofing strategy #1. Bulletproofing strategy #2 would instead say Category 2. 84 8.10 Parameter set kem/ntrulpr953 Category 4, as per bulletproofing strategy #1. Bulletproofing strategy #2 would instead say Category 3. 8.11 Parameter set kem/ntrulpr1013 Category 4, as per bulletproofing strategy #1. Bulletproofing strategy #2 would also say Category 4. 8.12 Parameter set kem/ntrulpr1277 Category 5, as per bulletproofing strategy #1. Bulletproofing strategy #2 would also say Category 5 It is hard to imagine any principled reason for NIST to have chosen 125, 174, 254 as the cutoffs corresponding to AES-128, AES-192, and AES-256 respectively. This suggests that 125 and 254 are overkill for bulletproofing. However, another possibility is that NIST will declare that [3] was mistaken in not complaining about the 174. Bulletproofing strategy #2 compensates for this by disregarding the 174, and replacing it with 181 from kyber768: • Assigning pre-quantum Core-SVP 2125 or larger to Category 1 is bulletproof. • Assigning pre-quantum Core-SVP 2141 or larger (post-quantum Core-SVP 2128 or 81 larger) to Category 2 is bulletproof. • Assigning pre-quantum Core-SVP 2181 or larger to Category 3 is bulletproof. • Assigning pre-quantum Core-SVP 2203 or larger (post-quantum Core-SVP 2184 or larger) to Category 4 is bulletproof. • Assigning pre-quantum Core-SVP 2254 or larger to Category 5 is bulletproof.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants