Loading in 5 sec....

Choosing NTRUEncrypt Parameters PowerPoint Presentation

Choosing NTRUEncrypt Parameters

- 102 Views
- Uploaded on

Download Presentation
## PowerPoint Slideshow about ' Choosing NTRUEncrypt Parameters ' - virote

**An Image/Link below is provided (as is) to download presentation**
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

Presentation Transcript

Agenda

- Parameter Generation
- How to pick parameters to obtain a given security level?
- We present a recipe for parameter generation
- Will 1363.1use this recipe, or simply the constraints that come out of it?

- Multiple parameter forms
- Standard form, product form

- Possible bandwidth savings – NTRU-KEM

- How to pick parameters to obtain a given security level?
- Key validation
- But first…

Review: NTRU parameters

- N, dimension of polynomial ring
- NTRU works on polynomials of degree N-1
- Polynomial multiplication is convolution multiplication: terms of degree > N are reduced mod N.
- For 80-bit security, N = 251.
- Increases roughly linearly with k for k-bit security

- q, “big” modulus
- All coefficients in polynomial are reduced mod q
- For 80-bit security, q = 239.
- Increases roughly linearly with k for k-bit security

- p, “small” modulus
- Reduce mod p during decryption
- p = 2, 2+X or 3 for all security levels.

- Sizes:
- Public key, ciphertext size = N log2 q = 2004 bits for 80-bit security
- message size (bits) = N log2 ||p|| = 251 bits for 80-bit security

Review: NTRUEncrypt Operations

- Key Generation
- Generate f, g, “small” polynomials in Zq[X]/(XN-1).
- Public key h = p*f-1*g mod q; private key = (f, fp = f-1 mod p).

- Encrypt (Raw operation)
- Encode message as “small” polynomial m.
- Generate “small” random polynomial r
- Ciphertext e = r*h + m mod q.

- Decrypt (Raw operation)
- Set a = f*e mod q.
- “mod q” = in range [A, A+q-1].

- Set m = fp * a mod p.

- Set a = f*e mod q.

Review: Why Decryption Works

- a = f * e (mod q) = f * (r*h + m) (mod q) = f * (r*p*g*Fq + m) (mod q) = p*r*g + f*m (mod q) since f*Fq = 1 (mod q)
- All of the polynomials r, g, f, m are small, so coefficients of p*r*g + f*mwill (usually) all lie within q of each other.
- If its coefficients are reduced into the right range, the polynomial a(x) is exactly equal to p*r*g + f*m. Then fp * a = p*r*g*fp (mod p) + fp*f*m (mod p) = m (mod p).
- Current parameter sets for 280 security include means for choosing this range. Choice of range fails on validly encrypted message one time in 2104.
- “Decryption failures”
- Attatcker gains information from decryption failures: wants to choose funky r, m.

Parameter Generation

- Input: k, the desired level of security
- Process:
- Choose N
- Set N to give necessary bandwidth

- Choose form of f, g, r
- Ensure combinatorial security

- Choose q, p
- Set q to prevent decryption failures

- Ensure that these parameters give appropriate lattice security

- Choose N
- There are many different ways of making these choices.
- These are the proposed ones for X9.98
- Note: extremely provisional and may change as the analysis proceeds

- Currently writing up a paper to formalize them

- These are the proposed ones for X9.98

Choose N

- With binary messages, N is the number of bits that can be transported
- For k bits of security for key transport, want to transport 2k bits of material
- Prevent birthday-like attacks based on future use of material

- For SVES-3, want to use at least k bits of random padding
- Gives security against enumeration attacks if encryption scheme is used to transport low-entropy messages

- Set N to be the first prime greater than 3k.

Choose form of f, g, r

- Our choice:
- Take f = 1+pF
- Speeds up decryption: f-1 mod p= 1, so we eliminate a convolution

- Take F, g, r to be binary with df, dg, dr 1s respectively.
- Number of additions necessary for convolution is df*N.

- Take f = 1+pF
- Alternatives:
- Take f not to be of form 1+pF
- Slows down decryption but reduces q (see next choice)

- Take f (or F), g, r to be of the form (e.g.) f = f1 * f2 + f3.
- “Product form”:
- Number of additions necessary for convolution is (f1 + f2 + f3)*N.
- Performance benefit

- Take f not to be of form 1+pF

Binary F, g, r: Combinatorial Security

- F, g, r have df, dg, dr 1s respectively
- Brute force-like search on F, g, r can be speeded up by meet-in-the-middle techniques.
- Using these techniques, number of binary convolution multiplications needed to break f is
- Each multiplication requires df.N additions
- … perhaps divided by 2-8 if we use wordsize cleverly
- In general, use number of multiplications as security measure

- Each multiplication requires df.N additions
- Attacker will go for easiest of (f, g), (r, m); pick df = dr = dg.

df, dg, dr for different security levels

- N and df, using the above criteria:
- df ~= 0.185 N.

Pick q, p

- Our choice:
- Pick p = 2, q to be the first prime greater than p.min(dr, dg) + 1 + p.min(df, N/2)with large order mod N.
- This gives zero chance of decryption failures
- Minimum q to do so consistent with choice of p, df.
- Best lattice security

- Pick p = 2, q to be the first prime greater than p.min(dr, dg) + 1 + p.min(df, N/2)with large order mod N.
- Alternatives:
- Take p = 2+X or 3, q = first power of 2 greater than p(1).min(dr, dg) + 1 + p(1).min(df, N/2)
- Taking q to be power of 2 speeds up reductions
- Larger value of p leads to larger q and worse lattice security

- Take p = 2, q = largest prime less than first power of 2 greater than p(1).min(dr, dg) + 1 + p(1).min(df, N/2)
- Speeds up reductions at expense of lattice security

- Allow a non-zero chance of decryption failures, if it can be determined to be less than 2-k.
- Reduces q, improves bandwidth and lattice security

- Take p = 2+X or 3, q = first power of 2 greater than p(1).min(dr, dg) + 1 + p(1).min(df, N/2)

df, q for different security levels

- N, df, q, using the above criteria:

Check Lattice Strength

- We characterize the lattice by two variables:
- c = (2N) . (2)||f||/s. = 2||f||(pe / q)
- Length of shortest vector [ (2)||f|| ]…
- Divided by expected length of shortest vector for lattice of the same determinant [ = (N q/pe) ]…
- Scaled by (2N) .

- a = N/q.

- c = (2N) . (2)||f||/s. = 2||f||(pe / q)
- Experimentally, breaking time is very sensitive to c, somewhat sensitive to a.
- Experimentally, for fixed c, a, breaking time is exponential in N.
- For all the parameter sets given in the previous slide, we have a >= 1.25, c >= 2.58.

Lattice Strength

- Based on the above experiments:
- Neglecting zero-forcing; also neglecting fact that the lattices under consideration are stronger than the ones experimented on.

More Notes on Parameter Generation

- Note how df affects lattice strength:
- For these parameters, q ~= 2pdf, ||f|| ~= df, c ~= ||f||/q
- c is ~independent of df!
- More precisely: ||f|| >= (df/2). Run expts for c = (pe / p) = 2.066?
- Rounding q up to next prime reduces min(c) slightly, not much.

- For these parameters, q ~= 2pdf, ||f|| ~= df, c ~= ||f||/q
- If we use the number of additions, not multiplications, as measure of combinatorial security, we can reduce df by typically 10-25%
- Gain decreases as N increases
- Reducing df reduces q potentially improves bandwidth

- Using product form (f = f1 * f2 + f3) improves efficiency but increases q
- Increased bandwidth, but typically only by one bit

- Using trinary (f, g) gives greater combinatorial security
- So many appealing choices…

Product Form

- Interested in meet-in-the-middle attacks on product form
- df1 = df2 = df3

- Standard search, described in Tech Note 4, takes on (f1*f2) and (f3)
- Could also remove a 1 from f2, add df 1s to f3

- df =~ 0.032 N for N = 251, 0.028 N for N = 769

Product Form Speedups, Keygen, Lattice Consideration

- Speed up typically factor of 2 over standard form
- Keygen will get slow for larger N -- haven’t done calculations
- For even larger N, guessing zeroes becomes better than guessing f
- Increased df doesn’t affect lattice strength (much)
- c = 2.05 experiments would still be fine

- Bandwidth increases only for k=160 and 192, by 1 bit per coeff

Parameters for NTRU-KEM

- Still taking p = 2.
- Now, only have to transmit about 2k bits, so can save bandwidth
- For k-bit security:
- Pick N = 2k
- Pick df = N/2
- Increase N until combinatorial security is > 2k.
- Take df, dr, dg, to be the same
- Take f=1+pF
- Set q as before

Parameter Sets

- This gives the following (note: c >= 2.05, so we omit it).
- In some cases, slightly increasing N decreases log2(q); we’ve done this where it helps. Note: q needs rounding up.

Speeding up?

- The parameters above successfully reduce bandwidth
- Can we improve speeds?
- Taking small polynomials to be {-1, 0, 1} improves combinatorial security
- Taking them to be {-2, -1, 0, 1, 2} would do even better, but…
- The wider the polynomials are, the wider2 their products are

Trinary polynomials

- Take p to be 3.
- f, g, r, m could be trinary
- Two different forms:
- Balanced: Equal +1s and –1s
- Biased: Minimum possible number of –1s
- Set N/2 1s, N/2 0s
- If this doesn’t give enough combinatorial security, set some of the 0s to –1s.
- Once there is adequate combinatorial security, see if we can reduce the number of 1s
- End with dg+ 1s, dg- -1s
- Combinatorial security estimated as sqrt ((N pick dg+)(N pick dg-)) / N
- This needs to be made more precise

Polynomial width

- Consider a*b:
- a has da+ +1s, da- -1s
- b has db+ +1s, db- -1s
- Maximum value if all +1s line up, all –1s line up.
- Minimum value if all +1s line up with –1s.
- Maximum width is Min(da+, db+) + Min(da-, db-) + Min(da+, db-) + Min(da-, db+)

- Advantage of having one balanced, one biased is we reduce this width compared to two balanced or two biased.
- Take f, r to be balanced trinary
- Gives lowest Hamming weight

- Take g to be biased trinary
- Consider m on next slide

Choosing N and encoding m

- Say we choose N to be ~2k
- Then biased polynomials have very few –1s.

- Want to transmit k bits of entropy
- Attacker can meet-in-the-middle on m’

- Could draw m’ from a space of 3N polynomials
- But this might be tiresome
- Open question: exactly how tiresome? Certainly tiresome in that output of Hash2 needs to be encoded as random trinary vector, involving repeated mod 3 divides of big integer

- Suggestion: Take b, output of Hash2, m’ to be binary
- Once m’ is generated, flip some terms (only 1s or only 0s) to –1s to obtain combinatorial security
- If more than (say) 4 need to be flipped, generate another b.

Recipe

- Choose N to be first prime > 2k
- Choose F, r to be balanced trinary
- (Actually, choose dr+ = dr- +1 for invertibility)

- Choose g to be biased trinary
- Choose f = 1+pF
- f(1) should not be 0 mod 2

- Say m’ will have no more than 4 –1s
- Maximum width is df + dr + dg- + 4
- Set q = the first power of 2 greater than this width

Parameter Sets

- This gives the following (note: c >= 2.11, so we omit it)
- df ~= 0.115 N, compared to 0.185 for SVES-3; time = N2.

Notes:

- We gain a speedup of a factor of about 2 over standard SVES-3
- Comparable to (though slightly worse than) speedup from move to product form
- Could consider product form here too, but there seem to be few advantages

- Bandwidth is about 0.65 of SVES-3 bandwidth
- Bandwidth is between 16 k and 18.3 k for security k
- Goes slightly worse than k, slightly better than k ln k.

- Lattice strength is a BIG question here
- Not clear that you can get 80 bits of lattice strength at N=163
- Equally, not 100% clear that you can’t….
- Can increase lattice strength by beefing up dg+, but this only goes so far

- Requires an additional SHA at the end
- But on fewer SHA compression blocks
- End up with about 2*0.65 = 1.3 as many SHA calls

Parameter Generation: Summary

- Outlined a possible parameter generation routine for NTRU
- Put in k, turn the handle, out come the parameters
- Parameters can be validated by third parties

- Specific parameter generation routine may change, but basic method remains the same:
- Choose N
- Choose form of f, g, r, m
- Choose q
- Check lattice strength; if too low, increase N to next prime and try again.

Open Questions

- How many parameter sets do we want?
- Optimize speed
- Optimize bandwidth
- Optimize for 8-bit processors?
- Can be done by increasing N decreasing q < 256 (or 128)

- Do we ever want to allow decryption failures for k > 80?

Open Research Questions

- Is it okay to use SHA-160 as the core hash function for k > 80?
- I think yes, but this needs discussion

Key Validation

- What can go wrong with an NTRUEncrypt public key h? Should be random mod q.
- Might be all zeroes
- Reveals message immediately

- If q is composite and gcd(hi, q) != 1 for all hi, might be possible to recover message from ciphertext by simple modular reduction.
- If h is too thin, such that r*h will have very few mod q reductions (< 2k effort to guess reduction locations), can recover message from ciphertext by linear algebra.

- Might be all zeroes
- Possible simple key validation procedure:
- Check that keys are not all the same value
- Check that sufficient number of hi have gcd(hi, q) = 1
- Check that width of h > c. q/df, c > 1 some parameter set dependent constant.

Key Validation (2)

- More sophisticated:
- Measure how “random” h looks. For example:
- Chance that a given mod q value does not occur anywhere in h = (1-1/q)N
- Find value l such that for random h the probability that l distinct values do not occur anywhere in h is less than 2-k.
- A different bound may be appropriate

- Count the number of distinct values that do not occur in h and reject if greater than l.

- Measure how “random” h looks. For example:
- Next draft will contain suggested text.

Issue: Forward Secrecy (1)

- NTRU key generation is efficient
- Can generate ephemeral keypairs easily

- This + next slide propose three ways of getting perfect forward secrecy using this fact
- Do these actually give forward secrecy?
- Do they give mutual authentication?
- Should they be included in the standard?

- (1) Say Alice has static keypairs (as, As).
- Bob generates ephemeral keypair (be, Be), sends Alice EAs(Be).
- This may have to be signed

- Alice uses Be as the public key for key transport or key agreement
- Afterwards, Bob disposes of (be, Be).

- Bob generates ephemeral keypair (be, Be), sends Alice EAs(Be).

Issue: Forward Secrecy (2)

- (2) Say Alice and Bob have static, certified keypairs (as, As), (bs, Bs).
- Bob generates ephemeral keypair (be, Be), sends Alice EAs(Be).
- Alice uses both Bs and Be in two runs of a key transport or key agreement mechanism, combines the two transported keys to get a single shared key.
- Afterwards, Bob disposes of (be, Be).

- (3) Say Alice and Bob have static, certified keypairs (as, As), (bs, Bs).
- Bob generates ephemeral keypair (be, Be), sends Alice EAs(Be).
- Alice generates ephemeral keypair (ae, Ae), sends Bob EBs(Ae).
- Alice uses Be to transport secret k1 to Bob
- Bob uses Ae to transport secret k2 to Alice
- Bob and Alice combine k1, k2 to get shared secret k.

- Note: need to define encryption carefully above: will probably be symmetric+public-key operation

That’s it!

- Questions?

Download Presentation

Connecting to Server..