Lattice Cryptography for the Internet Chris Peikert Georgia - - PowerPoint PPT Presentation

lattice cryptography for the internet chris peikert
SMART_READER_LITE
LIVE PREVIEW

Lattice Cryptography for the Internet Chris Peikert Georgia - - PowerPoint PPT Presentation

Lattice Cryptography for the Internet Chris Peikert Georgia Institute of Technology Post-Quantum Cryptography 2 October 2014 1 / 12 Lattice-Based Cryptography p d o m x g = y N = = p m e mod N q e ( g a , g b ) (Images


slide-1
SLIDE 1

Lattice Cryptography for the Internet Chris Peikert

Georgia Institute of Technology Post-Quantum Cryptography 2 October 2014

1 / 12

slide-2
SLIDE 2

Lattice-Based Cryptography

N = p · q

y = g

x

m

  • d

p

me mod N

e(ga, gb)

= ⇒

(Images courtesy xkcd.org) 2 / 12

slide-3
SLIDE 3

Lattice-Based Cryptography

= ⇒

(Images courtesy xkcd.org) 2 / 12

slide-4
SLIDE 4

Lattice-Based Cryptography

= ⇒

Amazing!

◮ Simple, efficient, and highly parallel crypto schemes ◮ Resists attacks by quantum algorithms (so far) ◮ Security from worst-case complexity assumptions ◮ Solves “holy grail” problems in crypto: FHE, obfuscation, . . .

(Images courtesy xkcd.org) 2 / 12

slide-5
SLIDE 5

A Decade of Lattice Crypto

◮ Trapdoor functions and CCA-secure encryption (w/o ROM)

3 / 12

slide-6
SLIDE 6

A Decade of Lattice Crypto

◮ Trapdoor functions and CCA-secure encryption (w/o ROM) ◮ Signatures schemes (w/ and w/o ROM)

3 / 12

slide-7
SLIDE 7

A Decade of Lattice Crypto

◮ Trapdoor functions and CCA-secure encryption (w/o ROM) ◮ Signatures schemes (w/ and w/o ROM) ◮ (Hierarchical) identity-based encryption

3 / 12

slide-8
SLIDE 8

A Decade of Lattice Crypto

◮ Trapdoor functions and CCA-secure encryption (w/o ROM) ◮ Signatures schemes (w/ and w/o ROM) ◮ (Hierarchical) identity-based encryption ◮ Attribute-based encryption

3 / 12

slide-9
SLIDE 9

A Decade of Lattice Crypto

◮ Trapdoor functions and CCA-secure encryption (w/o ROM) ◮ Signatures schemes (w/ and w/o ROM) ◮ (Hierarchical) identity-based encryption ◮ Attribute-based encryption ◮ Fully homomorphic encryption

3 / 12

slide-10
SLIDE 10

A Decade of Lattice Crypto

◮ Trapdoor functions and CCA-secure encryption (w/o ROM) ◮ Signatures schemes (w/ and w/o ROM) ◮ (Hierarchical) identity-based encryption ◮ Attribute-based encryption ◮ Fully homomorphic encryption ◮ Functional encryption

3 / 12

slide-11
SLIDE 11

A Decade of Lattice Crypto

◮ Trapdoor functions and CCA-secure encryption (w/o ROM) ◮ Signatures schemes (w/ and w/o ROM) ◮ (Hierarchical) identity-based encryption ◮ Attribute-based encryption ◮ Fully homomorphic encryption ◮ Functional encryption ◮ General-purpose obfuscation ◮ · · ·

3 / 12

slide-12
SLIDE 12

A Decade of Lattice Crypto

◮ Trapdoor functions and CCA-secure encryption (w/o ROM) ◮ Signatures schemes (w/ and w/o ROM) ◮ (Hierarchical) identity-based encryption ◮ Attribute-based encryption ◮ Fully homomorphic encryption ◮ Functional encryption ◮ General-purpose obfuscation ◮ · · ·

Meanwhile, in the Real World. . .

3 / 12

slide-13
SLIDE 13

A Decade of Lattice Crypto

◮ Trapdoor functions and CCA-secure encryption (w/o ROM) ◮ Signatures schemes (w/ and w/o ROM) ◮ (Hierarchical) identity-based encryption ◮ Attribute-based encryption ◮ Fully homomorphic encryption ◮ Functional encryption ◮ General-purpose obfuscation ◮ · · ·

Meanwhile, in the Real World. . .

◮ The vast majority of (public-key) crypto used in practice: signatures and key exchange/transport, over the Internet.

3 / 12

slide-14
SLIDE 14

This Work

◮ A first step towards Internet standards for lattice cryptography.

4 / 12

slide-15
SLIDE 15

This Work

◮ A first step towards Internet standards for lattice cryptography.

⋆ AKE from any passively secure KEM

(` a la IKEv2, RFC 5996)

4 / 12

slide-16
SLIDE 16

This Work

◮ A first step towards Internet standards for lattice cryptography.

⋆ AKE from any passively secure KEM

(` a la IKEv2, RFC 5996)

⋆ New, efficient KEMs from ring-LWE

(` a la RSA-KEM, RFC 5990)

4 / 12

slide-17
SLIDE 17

This Work

◮ A first step towards Internet standards for lattice cryptography.

⋆ AKE from any passively secure KEM

(` a la IKEv2, RFC 5996)

⋆ New, efficient KEMs from ring-LWE

(` a la RSA-KEM, RFC 5990)

◮ Technical contribution: a new ‘reconciliation’ mechanism yielding additive (not multiplicative) ciphertext overhead for lattice encryption.

4 / 12

slide-18
SLIDE 18

This Work

◮ A first step towards Internet standards for lattice cryptography.

⋆ AKE from any passively secure KEM

(` a la IKEv2, RFC 5996)

⋆ New, efficient KEMs from ring-LWE

(` a la RSA-KEM, RFC 5990)

◮ Technical contribution: a new ‘reconciliation’ mechanism yielding additive (not multiplicative) ciphertext overhead for lattice encryption.

⋆ Bit-for-bit encryption, plus fixed-size ‘prelude’ 4 / 12

slide-19
SLIDE 19

This Work

◮ A first step towards Internet standards for lattice cryptography.

⋆ AKE from any passively secure KEM

(` a la IKEv2, RFC 5996)

⋆ New, efficient KEMs from ring-LWE

(` a la RSA-KEM, RFC 5990)

◮ Technical contribution: a new ‘reconciliation’ mechanism yielding additive (not multiplicative) ciphertext overhead for lattice encryption.

⋆ Bit-for-bit encryption, plus fixed-size ‘prelude’ ⋆ Improves prior ciphertext sizes by up to 2x, at essentially no cost

(in security, runtime, key sizes, etc.)

4 / 12

slide-20
SLIDE 20

This Work

◮ A first step towards Internet standards for lattice cryptography.

⋆ AKE from any passively secure KEM

(` a la IKEv2, RFC 5996)

⋆ New, efficient KEMs from ring-LWE

(` a la RSA-KEM, RFC 5990)

◮ Technical contribution: a new ‘reconciliation’ mechanism yielding additive (not multiplicative) ciphertext overhead for lattice encryption.

⋆ Bit-for-bit encryption, plus fixed-size ‘prelude’ ⋆ Improves prior ciphertext sizes by up to 2x, at essentially no cost

(in security, runtime, key sizes, etc.)

⋆ Applies to all (ring-)LWE-based encryption schemes 4 / 12

slide-21
SLIDE 21

This Work

◮ A first step towards Internet standards for lattice cryptography.

⋆ AKE from any passively secure KEM

(` a la IKEv2, RFC 5996)

⋆ New, efficient KEMs from ring-LWE

(` a la RSA-KEM, RFC 5990)

◮ Technical contribution: a new ‘reconciliation’ mechanism yielding additive (not multiplicative) ciphertext overhead for lattice encryption.

⋆ Bit-for-bit encryption, plus fixed-size ‘prelude’ ⋆ Improves prior ciphertext sizes by up to 2x, at essentially no cost

(in security, runtime, key sizes, etc.)

⋆ Applies to all (ring-)LWE-based encryption schemes

◮ Not in this work: parameters, security estimates, implementation

4 / 12

slide-22
SLIDE 22

This Work

◮ A first step towards Internet standards for lattice cryptography.

⋆ AKE from any passively secure KEM

(` a la IKEv2, RFC 5996)

⋆ New, efficient KEMs from ring-LWE

(` a la RSA-KEM, RFC 5990)

◮ Technical contribution: a new ‘reconciliation’ mechanism yielding additive (not multiplicative) ciphertext overhead for lattice encryption.

⋆ Bit-for-bit encryption, plus fixed-size ‘prelude’ ⋆ Improves prior ciphertext sizes by up to 2x, at essentially no cost

(in security, runtime, key sizes, etc.)

⋆ Applies to all (ring-)LWE-based encryption schemes

◮ Not in this work: parameters, security estimates, implementation

⋆ Follow-up [BCNS’14]: TLS/SSL suite (in C) using these components,

with estimated > 128 bit security: practical!

4 / 12

slide-23
SLIDE 23

Authenticated Key Exchange

k k ◮ Basic Goal: mutually authenticate parties and provide them a “consistent view” of completed session (including key k).

5 / 12

slide-24
SLIDE 24

Authenticated Key Exchange

k k ◮ Basic Goal: mutually authenticate parties and provide them a “consistent view” of completed session (including key k). ◮ Adversary controls network, session initiation, may corrupt parties.

5 / 12

slide-25
SLIDE 25

Authenticated Key Exchange

k k ◮ Basic Goal: mutually authenticate parties and provide them a “consistent view” of completed session (including key k). ◮ Adversary controls network, session initiation, may corrupt parties. ◮ Many intricate models and definitions, offering strong guarantees.

[BR’93,BR’95,Kra’96,BCK’98,Sho’99,CK’01-02,LMQ’03,Kra’05,. . . ]

5 / 12

slide-26
SLIDE 26

Authenticated Key Exchange

◮ We focus on “SK-security with post-specified peer” model [CK’02a]

⋆ Designed explicitly with Internet in mind ⋆ ‘Responder’ identity is discovered during protocol; can conceal identities 6 / 12

slide-27
SLIDE 27

Authenticated Key Exchange

◮ We focus on “SK-security with post-specified peer” model [CK’02a]

⋆ Designed explicitly with Internet in mind ⋆ ‘Responder’ identity is discovered during protocol; can conceal identities

◮ A version of Krawczyk’s “SIGn-and-MAc” (SIGMA) protocol [Kra’03] satisfies this security definition, assuming DDH

6 / 12

slide-28
SLIDE 28

Authenticated Key Exchange

◮ We focus on “SK-security with post-specified peer” model [CK’02a]

⋆ Designed explicitly with Internet in mind ⋆ ‘Responder’ identity is discovered during protocol; can conceal identities

◮ A version of Krawczyk’s “SIGn-and-MAc” (SIGMA) protocol [Kra’03] satisfies this security definition, assuming DDH ◮ Internet Key Exchange (RFC 5996) based on this model & protocol

6 / 12

slide-29
SLIDE 29

Authenticated Key Exchange

◮ We focus on “SK-security with post-specified peer” model [CK’02a]

⋆ Designed explicitly with Internet in mind ⋆ ‘Responder’ identity is discovered during protocol; can conceal identities

◮ A version of Krawczyk’s “SIGn-and-MAc” (SIGMA) protocol [Kra’03] satisfies this security definition, assuming DDH ◮ Internet Key Exchange (RFC 5996) based on this model & protocol

Our Results

◮ We generalize SIGMA, replacing its underlying DH mechanism with any passively secure KEM.

6 / 12

slide-30
SLIDE 30

Authenticated Key Exchange

◮ We focus on “SK-security with post-specified peer” model [CK’02a]

⋆ Designed explicitly with Internet in mind ⋆ ‘Responder’ identity is discovered during protocol; can conceal identities

◮ A version of Krawczyk’s “SIGn-and-MAc” (SIGMA) protocol [Kra’03] satisfies this security definition, assuming DDH ◮ Internet Key Exchange (RFC 5996) based on this model & protocol

Our Results

◮ We generalize SIGMA, replacing its underlying DH mechanism with any passively secure KEM. ◮ This works because:

⋆ SIGMA has ‘initiator’ who speaks first: can send KEM public key ⋆ Security proof uses only ‘KEM-like’ properties of DH 6 / 12

slide-31
SLIDE 31

Authenticated Key Exchange

◮ We focus on “SK-security with post-specified peer” model [CK’02a]

⋆ Designed explicitly with Internet in mind ⋆ ‘Responder’ identity is discovered during protocol; can conceal identities

◮ A version of Krawczyk’s “SIGn-and-MAc” (SIGMA) protocol [Kra’03] satisfies this security definition, assuming DDH ◮ Internet Key Exchange (RFC 5996) based on this model & protocol

Our Results

◮ We generalize SIGMA, replacing its underlying DH mechanism with any passively secure KEM. ◮ This works because:

⋆ SIGMA has ‘initiator’ who speaks first: can send KEM public key ⋆ Security proof uses only ‘KEM-like’ properties of DH

◮ Bottom line: minor changes to protocol design should make standardization and implementation easier.

6 / 12

slide-32
SLIDE 32

Key Encapsulation/Transport (KEM)

Encaps pk k Decaps sk k c

7 / 12

slide-33
SLIDE 33

Key Encapsulation/Transport (KEM)

Encaps pk k Decaps sk k c ◮ Passive security: (pk, c, k)

c

≈ (pk, c, k∗) where k∗ uniform & independ.

7 / 12

slide-34
SLIDE 34

Key Encapsulation/Transport (KEM)

Encaps pk k Decaps sk k c ◮ Passive security: (pk, c, k)

c

≈ (pk, c, k∗) where k∗ uniform & independ. ◮ Active (CCA) security: same, even with Decapssk(·) oracle

7 / 12

slide-35
SLIDE 35

Key Encapsulation/Transport (KEM)

Encaps pk k Decaps sk k c ◮ Passive security: (pk, c, k)

c

≈ (pk, c, k∗) where k∗ uniform & independ. ◮ Active (CCA) security: same, even with Decapssk(·) oracle Some practical actively secure KEMs:

1 RSA-OAEP [BR’94,Shoup’01]:

security from RSA (in ROM)

7 / 12

slide-36
SLIDE 36

Key Encapsulation/Transport (KEM)

Encaps pk k Decaps sk k c ◮ Passive security: (pk, c, k)

c

≈ (pk, c, k∗) where k∗ uniform & independ. ◮ Active (CCA) security: same, even with Decapssk(·) oracle Some practical actively secure KEMs:

1 RSA-OAEP [BR’94,Shoup’01]:

security from RSA (in ROM)

2 RSA-KEM (RFC 5990):

from RSA (in ROM)

7 / 12

slide-37
SLIDE 37

Key Encapsulation/Transport (KEM)

Encaps pk k Decaps sk k c ◮ Passive security: (pk, c, k)

c

≈ (pk, c, k∗) where k∗ uniform & independ. ◮ Active (CCA) security: same, even with Decapssk(·) oracle Some practical actively secure KEMs:

1 RSA-OAEP [BR’94,Shoup’01]:

security from RSA (in ROM)

2 RSA-KEM (RFC 5990):

from RSA (in ROM)

3 “Hashed ElGamal” [BR’97,CS’98,ABR’01]:

from DDH (in ROM)

7 / 12

slide-38
SLIDE 38

Key Encapsulation/Transport (KEM)

Encaps pk k Decaps sk k c ◮ Passive security: (pk, c, k)

c

≈ (pk, c, k∗) where k∗ uniform & independ. ◮ Active (CCA) security: same, even with Decapssk(·) oracle Some practical actively secure KEMs:

1 RSA-OAEP [BR’94,Shoup’01]:

security from RSA (in ROM)

2 RSA-KEM (RFC 5990):

from RSA (in ROM)

3 “Hashed ElGamal” [BR’97,CS’98,ABR’01]:

from DDH (in ROM)

4 REACT transform [OP’01]:

from inj. trapdoor function (in ROM)

7 / 12

slide-39
SLIDE 39

Key Encapsulation/Transport (KEM)

Encaps pk k Decaps sk k c ◮ Passive security: (pk, c, k)

c

≈ (pk, c, k∗) where k∗ uniform & independ. ◮ Active (CCA) security: same, even with Decapssk(·) oracle Some practical actively secure KEMs:

1 RSA-OAEP [BR’94,Shoup’01]:

security from RSA (in ROM)

2 RSA-KEM (RFC 5990):

from RSA (in ROM)

3 “Hashed ElGamal” [BR’97,CS’98,ABR’01]:

from DDH (in ROM)

4 REACT transform [OP’01]:

from inj. trapdoor function (in ROM)

5 FO transforms [FO’99a,b]:

from any CPA-secure encryption (in ROM)

7 / 12

slide-40
SLIDE 40

Key Encapsulation/Transport: Our Results

Passive Security

◮ We construct a KEM from ring-LWE (` a la [LPR’10,LPR’13]), with a new ‘error reconciliation’ mechanism: ≈ 2x smaller ciphertexts

8 / 12

slide-41
SLIDE 41

Key Encapsulation/Transport: Our Results

Passive Security

◮ We construct a KEM from ring-LWE (` a la [LPR’10,LPR’13]), with a new ‘error reconciliation’ mechanism: ≈ 2x smaller ciphertexts

Active Security

◮ There are many construction paradigms, and (semi)generic transformations, for actively secure KEM/encryption schemes.

8 / 12

slide-42
SLIDE 42

Key Encapsulation/Transport: Our Results

Passive Security

◮ We construct a KEM from ring-LWE (` a la [LPR’10,LPR’13]), with a new ‘error reconciliation’ mechanism: ≈ 2x smaller ciphertexts

Active Security

◮ There are many construction paradigms, and (semi)generic transformations, for actively secure KEM/encryption schemes. ◮ Most are inapplicable, inefficient, or insecure for our KEM!

8 / 12

slide-43
SLIDE 43

Key Encapsulation/Transport: Our Results

Passive Security

◮ We construct a KEM from ring-LWE (` a la [LPR’10,LPR’13]), with a new ‘error reconciliation’ mechanism: ≈ 2x smaller ciphertexts

Active Security

◮ There are many construction paradigms, and (semi)generic transformations, for actively secure KEM/encryption schemes. ◮ Most are inapplicable, inefficient, or insecure for our KEM!

✗ “Hashed ElGamal:” insecure due to ring-LWE search/decision equiv.

8 / 12

slide-44
SLIDE 44

Key Encapsulation/Transport: Our Results

Passive Security

◮ We construct a KEM from ring-LWE (` a la [LPR’10,LPR’13]), with a new ‘error reconciliation’ mechanism: ≈ 2x smaller ciphertexts

Active Security

◮ There are many construction paradigms, and (semi)generic transformations, for actively secure KEM/encryption schemes. ◮ Most are inapplicable, inefficient, or insecure for our KEM!

✗ “Hashed ElGamal:” insecure due to ring-LWE search/decision equiv. ✗ REACT: insecure: ring-LWE is not OW-PCA, for same reason

8 / 12

slide-45
SLIDE 45

Key Encapsulation/Transport: Our Results

Passive Security

◮ We construct a KEM from ring-LWE (` a la [LPR’10,LPR’13]), with a new ‘error reconciliation’ mechanism: ≈ 2x smaller ciphertexts

Active Security

◮ There are many construction paradigms, and (semi)generic transformations, for actively secure KEM/encryption schemes. ◮ Most are inapplicable, inefficient, or insecure for our KEM!

✗ “Hashed ElGamal:” insecure due to ring-LWE search/decision equiv. ✗ REACT: insecure: ring-LWE is not OW-PCA, for same reason ✗ OAEP, REACT: inapplicable: need inj. trapdoor funcs (Use [MP’12]?)

8 / 12

slide-46
SLIDE 46

Key Encapsulation/Transport: Our Results

Passive Security

◮ We construct a KEM from ring-LWE (` a la [LPR’10,LPR’13]), with a new ‘error reconciliation’ mechanism: ≈ 2x smaller ciphertexts

Active Security

◮ There are many construction paradigms, and (semi)generic transformations, for actively secure KEM/encryption schemes. ◮ Most are inapplicable, inefficient, or insecure for our KEM!

✗ “Hashed ElGamal:” insecure due to ring-LWE search/decision equiv. ✗ REACT: insecure: ring-LWE is not OW-PCA, for same reason ✗ OAEP, REACT: inapplicable: need inj. trapdoor funcs (Use [MP’12]?) ✔ FO transforms: these work!

  • Prefer [FO’99b] because it maintains plaintext length
  • Subtlety: RO yields random coins for encryption (Gaussian sampling)

8 / 12

slide-47
SLIDE 47

New Reconciliation Mechanism

◮ In most prior lattice encryption schemes:

9 / 12

slide-48
SLIDE 48

New Reconciliation Mechanism

◮ In most prior lattice encryption schemes:

⋆ Sender encodes each msg bit µ ∈ Z2 = {0, 1} as v = µ · ⌊ q

2⌋ ∈ Zq.

9 / 12

slide-49
SLIDE 49

New Reconciliation Mechanism

◮ In most prior lattice encryption schemes:

⋆ Sender encodes each msg bit µ ∈ Z2 = {0, 1} as v = µ · ⌊ q

2⌋ ∈ Zq.

⋆ Receiver recovers w ≈ µ · ⌊ q

2⌋, where ≈ comes from LWE error.

9 / 12

slide-50
SLIDE 50

New Reconciliation Mechanism

◮ In most prior lattice encryption schemes:

⋆ Sender encodes each msg bit µ ∈ Z2 = {0, 1} as v = µ · ⌊ q

2⌋ ∈ Zq.

⋆ Receiver recovers w ≈ µ · ⌊ q

2⌋, where ≈ comes from LWE error.

⋆ Receiver computes µ by ‘rounding:’ µ = ⌊v⌉2 := ⌊ 2

q · v⌉ ∈ Z2.

9 / 12

slide-51
SLIDE 51

New Reconciliation Mechanism

◮ In most prior lattice encryption schemes:

⋆ Sender encodes each msg bit µ ∈ Z2 = {0, 1} as v = µ · ⌊ q

2⌋ ∈ Zq.

⋆ Receiver recovers w ≈ µ · ⌊ q

2⌋, where ≈ comes from LWE error.

⋆ Receiver computes µ by ‘rounding:’ µ = ⌊v⌉2 := ⌊ 2

q · v⌉ ∈ Z2.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 v w

9 / 12

slide-52
SLIDE 52

New Reconciliation Mechanism

◮ In most prior lattice encryption schemes:

⋆ Sender encodes each msg bit µ ∈ Z2 = {0, 1} as v = µ · ⌊ q

2⌋ ∈ Zq.

⋆ Receiver recovers w ≈ µ · ⌊ q

2⌋, where ≈ comes from LWE error.

⋆ Receiver computes µ by ‘rounding:’ µ = ⌊v⌉2 := ⌊ 2

q · v⌉ ∈ Z2.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 v w

◮ Problem: log q factor overhead per msg bit (plus ctext ‘preamble’).

9 / 12

slide-53
SLIDE 53

New Reconciliation Mechanism

◮ Contribution: bit-for-bit error-tolerant reconciliation.

10 / 12

slide-54
SLIDE 54

New Reconciliation Mechanism

◮ Contribution: bit-for-bit error-tolerant reconciliation. ◮ Sender has (pseudo)random v ∈ Zq, receiver can recover w ≈ v.

10 / 12

slide-55
SLIDE 55

New Reconciliation Mechanism

◮ Contribution: bit-for-bit error-tolerant reconciliation. ◮ Sender has (pseudo)random v ∈ Zq, receiver can recover w ≈ v. ◮ For even q, define ‘cross-rounding’ function v2 := ⌊ 4

q · v⌋ mod 2.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

10 / 12

slide-56
SLIDE 56

New Reconciliation Mechanism

◮ Contribution: bit-for-bit error-tolerant reconciliation. ◮ Sender has (pseudo)random v ∈ Zq, receiver can recover w ≈ v. ◮ For even q, define ‘cross-rounding’ function v2 := ⌊ 4

q · v⌋ mod 2.

Encoding of ⌊v⌉2 is v2 ∈ {0, 1}. (Maybe biased; doesn’t matter!)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 v

10 / 12

slide-57
SLIDE 57

New Reconciliation Mechanism

◮ Contribution: bit-for-bit error-tolerant reconciliation. ◮ Sender has (pseudo)random v ∈ Zq, receiver can recover w ≈ v. ◮ For even q, define ‘cross-rounding’ function v2 := ⌊ 4

q · v⌋ mod 2.

Encoding of ⌊v⌉2 is v2 ∈ {0, 1}. (Maybe biased; doesn’t matter!)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 v

Claim 1: if v ∈ Zq is uniform, then ⌊v⌉2 is uniform given v2.

10 / 12

slide-58
SLIDE 58

New Reconciliation Mechanism

◮ Contribution: bit-for-bit error-tolerant reconciliation. ◮ Sender has (pseudo)random v ∈ Zq, receiver can recover w ≈ v. ◮ For even q, define ‘cross-rounding’ function v2 := ⌊ 4

q · v⌋ mod 2.

Encoding of ⌊v⌉2 is v2 ∈ {0, 1}. (Maybe biased; doesn’t matter!)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 v w

Claim 1: if v ∈ Zq is uniform, then ⌊v⌉2 is uniform given v2. Claim 2: given v2 and any w ≈ v, can recover ⌊v⌉2.

10 / 12

slide-59
SLIDE 59

New Reconciliation Mechanism

◮ Contribution: bit-for-bit error-tolerant reconciliation. ◮ Sender has (pseudo)random v ∈ Zq, receiver can recover w ≈ v. ◮ For even q, define ‘cross-rounding’ function v2 := ⌊ 4

q · v⌋ mod 2.

Encoding of ⌊v⌉2 is v2 ∈ {0, 1}. (Maybe biased; doesn’t matter!)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 v w

Claim 1: if v ∈ Zq is uniform, then ⌊v⌉2 is uniform given v2. Claim 2: given v2 and any w ≈ v, can recover ⌊v⌉2.

10 / 12

slide-60
SLIDE 60

New Reconciliation Mechanism

◮ Contribution: bit-for-bit error-tolerant reconciliation. ◮ Sender has (pseudo)random v ∈ Zq, receiver can recover w ≈ v. ◮ For even q, define ‘cross-rounding’ function v2 := ⌊ 4

q · v⌋ mod 2.

Encoding of ⌊v⌉2 is v2 ∈ {0, 1}. (Maybe biased; doesn’t matter!)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 v w

Claim 1: if v ∈ Zq is uniform, then ⌊v⌉2 is uniform given v2. Claim 2: given v2 and any w ≈ v, can recover ⌊v⌉2.

10 / 12

slide-61
SLIDE 61

The Ring-LWE KEM

◮ Let R = Z[X]/(Xn + 1) for n a power of two, and Rq = R/qR

⋆ Elts of R (Rq) are deg < n polynomials with integer (mod q) coeffs. ⋆ ‘Errors’ in R are polynomials with small (Gaussian) integer coefficients. ⋆ Operations in Rq are very efficient using FFT-like algorithms. 11 / 12

slide-62
SLIDE 62

The Ring-LWE KEM

◮ Let R = Z[X]/(Xn + 1) for n a power of two, and Rq = R/qR

⋆ Elts of R (Rq) are deg < n polynomials with integer (mod q) coeffs. ⋆ ‘Errors’ in R are polynomials with small (Gaussian) integer coefficients. ⋆ Operations in Rq are very efficient using FFT-like algorithms.

◮ Public key is (a, b ≈ a · s) ∈ Rq × Rq for secret error s ∈ R.

11 / 12

slide-63
SLIDE 63

The Ring-LWE KEM

◮ Let R = Z[X]/(Xn + 1) for n a power of two, and Rq = R/qR

⋆ Elts of R (Rq) are deg < n polynomials with integer (mod q) coeffs. ⋆ ‘Errors’ in R are polynomials with small (Gaussian) integer coefficients. ⋆ Operations in Rq are very efficient using FFT-like algorithms.

◮ Public key is (a, b ≈ a · s) ∈ Rq × Rq for secret error s ∈ R. ◮ Encaps: choose error r ∈ R, let u ≈ r · a, v ≈ r · b ∈ Rq, output c = (u , v2) ∈ Rq × R2, key k = ⌊v⌉2 ∈ R2.

11 / 12

slide-64
SLIDE 64

The Ring-LWE KEM

◮ Let R = Z[X]/(Xn + 1) for n a power of two, and Rq = R/qR

⋆ Elts of R (Rq) are deg < n polynomials with integer (mod q) coeffs. ⋆ ‘Errors’ in R are polynomials with small (Gaussian) integer coefficients. ⋆ Operations in Rq are very efficient using FFT-like algorithms.

◮ Public key is (a, b ≈ a · s) ∈ Rq × Rq for secret error s ∈ R. ◮ Encaps: choose error r ∈ R, let u ≈ r · a, v ≈ r · b ∈ Rq, output c = (u , v2) ∈ Rq × R2, key k = ⌊v⌉2 ∈ R2. ◮ Decaps: recover k = ⌊v⌉2 from v2 and w = u · s ≈ r · a · s ≈ r · b ≈ v.

11 / 12

slide-65
SLIDE 65

The Ring-LWE KEM

◮ Let R = Z[X]/(Xn + 1) for n a power of two, and Rq = R/qR

⋆ Elts of R (Rq) are deg < n polynomials with integer (mod q) coeffs. ⋆ ‘Errors’ in R are polynomials with small (Gaussian) integer coefficients. ⋆ Operations in Rq are very efficient using FFT-like algorithms.

◮ Public key is (a, b ≈ a · s) ∈ Rq × Rq for secret error s ∈ R. ◮ Encaps: choose error r ∈ R, let u ≈ r · a, v ≈ r · b ∈ Rq, output c = (u , v2) ∈ Rq × R2, key k = ⌊v⌉2 ∈ R2. ◮ Decaps: recover k = ⌊v⌉2 from v2 and w = u · s ≈ r · a · s ≈ r · b ≈ v. ◮ Passively secure under ring-LWE [LPR’10].

11 / 12

slide-66
SLIDE 66

The Ring-LWE KEM

◮ Let R = Z[X]/(Xn + 1) for n a power of two, and Rq = R/qR

⋆ Elts of R (Rq) are deg < n polynomials with integer (mod q) coeffs. ⋆ ‘Errors’ in R are polynomials with small (Gaussian) integer coefficients. ⋆ Operations in Rq are very efficient using FFT-like algorithms.

◮ Public key is (a, b ≈ a · s) ∈ Rq × Rq for secret error s ∈ R. ◮ Encaps: choose error r ∈ R, let u ≈ r · a, v ≈ r · b ∈ Rq, output c = (u , v2) ∈ Rq × R2, key k = ⌊v⌉2 ∈ R2. ◮ Decaps: recover k = ⌊v⌉2 from v2 and w = u · s ≈ r · a · s ≈ r · b ≈ v. ◮ Passively secure under ring-LWE [LPR’10]. ◮ Generalizes (tightly!) to any cyclotomic ring using tools from [LPR’13].

11 / 12

slide-67
SLIDE 67

Conclusions and Future Work

◮ We have taken one (small) step toward “making the Internet safe for lattice cryptography” (or vice versa?)

12 / 12

slide-68
SLIDE 68

Conclusions and Future Work

◮ We have taken one (small) step toward “making the Internet safe for lattice cryptography” (or vice versa?) ◮ Much remains to be done: signature protocols, implementations, formal standards, . . .

12 / 12

slide-69
SLIDE 69

Conclusions and Future Work

◮ We have taken one (small) step toward “making the Internet safe for lattice cryptography” (or vice versa?) ◮ Much remains to be done: signature protocols, implementations, formal standards, . . . ◮ Please help!

12 / 12

slide-70
SLIDE 70

Conclusions and Future Work

◮ We have taken one (small) step toward “making the Internet safe for lattice cryptography” (or vice versa?) ◮ Much remains to be done: signature protocols, implementations, formal standards, . . . ◮ Please help!

Thanks!

12 / 12