Giter Site home page Giter Site logo

Comments (1)

syonfox avatar syonfox commented on June 15, 2024

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.

from sntrup4591761.

Related Issues (1)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.