Comments (1)
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sntrup4591761.