X9.98 Top N issues

1. X9.98Top N issues William Whyte, October 2003

2. 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

3. 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.

4. 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.

5. Review: SVES-3 encryption mLen 00… b m ID Hash r r*h XOR Hash m’ r*h + m’ e

6. Properties of SVES-3 encryption • Efficient (encryption requires 1 convolution, decryption requires 2) • Tight reduction (linear in calls to hash function) • Secure in the presence of decryption failures, so long as their average chance of occurrence is negligible • Adversary can’t construct messages and obtain higher than average chance of decryption failure; can’t construct new queries based on manipulating messages that have given decryption failures. • Size of randomness for k-bit security = k bits • For 80-bit (N=251), maximum plaintext size = 160 bits vs ciphertext size of 2004 bits.

7. Issues

8. X9.98 • NTRUEncrypt is a public-key encryption algorithm similar to RSA • It makes sense to have as much material as possible in common with X9.44 • Survey issues arising in trying to “port” X9.44 to NTRU

9. Issue: Can we say “NTRU”? • When we were approving the NWI, used the term LBP-PKE (Lattice Based Polynomial Public Key Encryption) to avoid trademarks • … but “RSA” is used throughout X9.44 • … and the ASN.1, defined in EESS#1, uses the string “ntru”. • I’ll use NTRU throughout this presentation for (my own) convenience

10. Issues • Key “Exchange”? • See X9.44… • Key confirmation • X9.44 text is not RSA-specific: suggest keeping it. • Key transport and agreement schemes • Appears that schemes in X9.44 can be adopted more or less wholesale • Possibly kas1-bilateral-confirmation-initiator-authentication can be omitted as devices that use NTRU might be too constrained to use a signing/verification algorithm as well

11. Issue: KEM? • X9.44 contains RSAES-PKCS1-v1_5, RSAES-OAEP and RSAES-KEM-KWS • Motivation for PKCS1v1.5: Interoperability • Motivation for OAEP: Interop plus some level of provable security. • Motivation for KEM: Reduction is tighter in proof of security, plus slightly cleaner construction which prevents Manger-like attacks. • NTRU-KEM possiblities: • e = r*h + m, m random, k = H(m) • Not secure! Attacker can add multiples of p to m, can make r non-binary, and increase probability of decryption failure • Variant of SVES-3 where b takes up entire block, k = H(b) • Now for k-bit security we have to transmit only 2k bits, instead of 2k bits of message and k bits of padding • Might make it possible to get the same security at lower N • Should we have a KEM?

12. Issue: Parameter Validation • A set of NTRU domain parameters is • N, p, q, introduced already • Description of form of f, g, r, m (eg binary with df 1s) • For any desired level of security, there are many different sets of parameters. • In general, one can keep a constant level of security by decreasing the Hamming weight of f, g and increasing N • Current intention is to provide one or more sets of parameters for each security level (80, 112, 128, 160, 192, 256) • Require that these are used • “Parameter validation” consists of checking the parameter set is on the approved list • Not clear that there are advantages to allowing users to generate their own parameter sets

13. Issue: Key Validation • Recall Lim-Lee attack on DL problems: by interacting with a bad public key I can expose my private key • No similar attacks known on NTRU; worst that can happen is that individual messages get exposed. • Propose similar approach to X9.44 • Separate keypair validation and public key validation • Keypair validation: simply ensure that f, g have the form given in the parameter set, and that h = pg/f mod q. • May choose to store seed for f, g instead of f, g themselves • Partial public key validation: • Encryption will be insecure unless there is a reasonable amount of mod q reduction when calculating r*h mod q. • Check that h has a certain thickness, such that for random r there will be this reduction.

14. 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).

15. 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

16. Issue: Hash Function Strength • Incorporate any hash function comments arising from X9.44 discussion • Note: Is it necessary to require collision-resistance or preimage-resistance in MGF? • Is SHA-1 appropriate up to 160 bits or 80 bits? • Preimage-resistant strength may affect proof of security in random oracle model; not clear that collision-resistance does • This is relevant because SHA-1 is so much faster than the longer hash algorithms • NTRU is sufficiently fast that time spent hashing can be a significant amount of the total time spend on encryption/decryption • Should also discuss number of bits in b required for specific security level

17. Schedule • Hope to post new version of X9.98 with these issues addressed by end of November • Any other issues?