session id: cryp-f03 practical, anonymous, … · session id: cryp-f03 practical, anonymous, and...

SESSION ID: CRYP-F03PRACTICAL, ANONYMOUS, AND PUBLICLYLINKABLE UNIVERSALLY-COMPOSABLEREPUTATION SYSTEMS

Jakob JuhnkePhD Student/Research AssistantPaderborn UniversityPaderborn, Germany

Why do we need reputation systems?

Customers and product providers want to get valuable information about previoustransactions:• Customers:• What kind of experiences have other people had with this product?• Does the product cover my needs?• Is the product worth its price?• Providers:• How can I improve my products to fit the customer’s needs?• Are my products easy to use?• Are products from other providers better/worse than mine and why?

2

Why do we need reputation systems?Customers and product providers want to get valuable information about previoustransactions:

• Customers:• What kind of experiences have other people had with this product?• Does the product cover my needs?• Is the product worth its price?• Providers:• How can I improve my products to fit the customer’s needs?• Are my products easy to use?• Are products from other providers better/worse than mine and why?

2

Why do we need reputation systems?Customers and product providers want to get valuable information about previoustransactions:• Customers:• What kind of experiences have other people had with this product?• Does the product cover my needs?• Is the product worth its price?

• Providers:• How can I improve my products to fit the customer’s needs?• Are my products easy to use?• Are products from other providers better/worse than mine and why?

2

Why do we need reputation systems?Customers and product providers want to get valuable information about previoustransactions:• Customers:• What kind of experiences have other people had with this product?• Does the product cover my needs?• Is the product worth its price?• Providers:• How can I improve my products to fit the customer’s needs?• Are my products easy to use?• Are products from other providers better/worse than mine and why?

2

Desirable propertiesWe want trustworthy, reliable and honest ratings:

• Customers want:→ Raters stay anonymous→ Verifiable binding of transactions and ratings→ Everyone is able to detect multiple ratings from the same user→ Providers are not able to rate their own products

• Providers want:→ Raters allowed to rate purchased products only once→ In case of misuse: anonymity of raters should be rescinded→ Ratings should be arbitrary strings to support arbitrary higher-level protocols

3

Desirable propertiesWe want trustworthy, reliable and honest ratings:• Customers want:

→ Raters stay anonymous→ Verifiable binding of transactions and ratings→ Everyone is able to detect multiple ratings from the same user→ Providers are not able to rate their own products

• Providers want:→ Raters allowed to rate purchased products only once→ In case of misuse: anonymity of raters should be rescinded→ Ratings should be arbitrary strings to support arbitrary higher-level protocols

3

Our starting point

What we already have:[BJK15] Blömer, Juhnke, Kolb: Anonymous and Publicly Linkable Reputation Systems,Financial Cryptography and Data Security (FC) 2015:• Definition of an abstract model for reputation systems• Experiment-based security definitions for anonymity, public linkability,traceability, and strong-exculpability• Concrete scheme based on group signatures• Drawbacks: Security definitions use 11 oracles (plus 3 random oracles)

Customers and providers are distinct sets

4

Our starting pointWhat we already have:[BJK15] Blömer, Juhnke, Kolb: Anonymous and Publicly Linkable Reputation Systems,Financial Cryptography and Data Security (FC) 2015:

• Definition of an abstract model for reputation systems• Experiment-based security definitions for anonymity, public linkability,traceability, and strong-exculpability• Concrete scheme based on group signatures• Drawbacks: Security definitions use 11 oracles (plus 3 random oracles)Customers and providers are distinct sets

4

Our starting pointWhat we already have:[BJK15] Blömer, Juhnke, Kolb: Anonymous and Publicly Linkable Reputation Systems,Financial Cryptography and Data Security (FC) 2015:• Definition of an abstract model for reputation systems

• Experiment-based security definitions for anonymity, public linkability,traceability, and strong-exculpability• Concrete scheme based on group signatures• Drawbacks: Security definitions use 11 oracles (plus 3 random oracles)Customers and providers are distinct sets

4

Our starting pointWhat we already have:[BJK15] Blömer, Juhnke, Kolb: Anonymous and Publicly Linkable Reputation Systems,Financial Cryptography and Data Security (FC) 2015:• Definition of an abstract model for reputation systems• Experiment-based security definitions for anonymity, public linkability,traceability, and strong-exculpability

• Concrete scheme based on group signatures• Drawbacks: Security definitions use 11 oracles (plus 3 random oracles)Customers and providers are distinct sets

4

Our starting pointWhat we already have:[BJK15] Blömer, Juhnke, Kolb: Anonymous and Publicly Linkable Reputation Systems,Financial Cryptography and Data Security (FC) 2015:• Definition of an abstract model for reputation systems• Experiment-based security definitions for anonymity, public linkability,traceability, and strong-exculpability• Concrete scheme based on group signatures

• Drawbacks: Security definitions use 11 oracles (plus 3 random oracles)Customers and providers are distinct sets

4

Our starting pointWhat we already have:[BJK15] Blömer, Juhnke, Kolb: Anonymous and Publicly Linkable Reputation Systems,Financial Cryptography and Data Security (FC) 2015:• Definition of an abstract model for reputation systems• Experiment-based security definitions for anonymity, public linkability,traceability, and strong-exculpability• Concrete scheme based on group signatures• Drawbacks: Security definitions use 11 oracles (plus 3 random oracles)

Customers and providers are distinct sets4

Our Goals

What we want:• Remove the strict separation of customers and providers→ Treat them as different roles of the same party• “Simplify” security definitions→ Circumvent oracles→ Combine the different security experiments• Cover additional security properties

→ Formulate an ideal functionality for reputation systems

Our result: a holistic functionality that also covers initially unexpected securityproperties

5

Our GoalsWhat we want:• Remove the strict separation of customers and providers

→ Treat them as different roles of the same party

• “Simplify” security definitions→ Circumvent oracles→ Combine the different security experiments• Cover additional security properties



5


→ Treat them as different roles of the same party• “Simplify” security definitions→ Circumvent oracles→ Combine the different security experiments

• Cover additional security properties→ Formulate an ideal functionality for reputation systems


5


→ Treat them as different roles of the same party• “Simplify” security definitions→ Circumvent oracles→ Combine the different security experiments• Cover additional security properties



5


→ Treat them as different roles of the same party• “Simplify” security definitions→ Circumvent oracles→ Combine the different security experiments• Cover additional security properties


Our result: a holistic functionality that also covers initially unexpected securityproperties5

Why Universal Composability?

• Reputation systems are often integrated into other applications• Experiment-based security definitions only guarantee stand-alone security• We exclude concrete reputation functions as they are application specificBut:• we want a system that can be combined with every reputation function• possible to incorporate into every application

⇒ Composition of protocols is explicitly desired⇒ Universal Composability is the framework of our choice (Canetti, 2001)

6


• Reputation systems are often integrated into other applications• Experiment-based security definitions only guarantee stand-alone security• We exclude concrete reputation functions as they are application specific

But:• we want a system that can be combined with every reputation function• possible to incorporate into every application⇒ Composition of protocols is explicitly desired⇒ Universal Composability is the framework of our choice (Canetti, 2001)

6


• Reputation systems are often integrated into other applications• Experiment-based security definitions only guarantee stand-alone security• We exclude concrete reputation functions as they are application specificBut:• we want a system that can be combined with every reputation function

• possible to incorporate into every application⇒ Composition of protocols is explicitly desired⇒ Universal Composability is the framework of our choice (Canetti, 2001)

6


• Reputation systems are often integrated into other applications• Experiment-based security definitions only guarantee stand-alone security• We exclude concrete reputation functions as they are application specificBut:• we want a system that can be combined with every reputation function• possible to incorporate into every application

⇒ Composition of protocols is explicitly desired⇒ Universal Composability is the framework of our choice (Canetti, 2001)

6

The Basic Model - 1/2Our model consists of one Identity Manager and a group of users with different roles:

• Identity Manager:• User Registration, avoiding double-registration• De-Anonymization in case of misbehaving users• User acting as Seller/Product Owner:• Publish product-specific keys• hand Rating-Tokens to designated Raters• User acting as Rater:• use registration information and rating token to rate aspecific product

BP

Seller

RaterOutsider

7

The Basic Model - 1/2Our model consists of one Identity Manager and a group of users with different roles:• Identity Manager:• User Registration, avoiding double-registration• De-Anonymization in case of misbehaving users

• User acting as Seller/Product Owner:• Publish product-specific keys• hand Rating-Tokens to designated Raters• User acting as Rater:• use registration information and rating token to rate aspecific product

BP

Seller

RaterOutsider

7

The Basic Model - 1/2Our model consists of one Identity Manager and a group of users with different roles:• Identity Manager:• User Registration, avoiding double-registration• De-Anonymization in case of misbehaving users• User acting as Seller/Product Owner:• Publish product-specific keys• hand Rating-Tokens to designated Raters

• User acting as Rater:• use registration information and rating token to rate aspecific product

BP

Seller

RaterOutsider

7

The Basic Model - 1/2Our model consists of one Identity Manager and a group of users with different roles:• Identity Manager:• User Registration, avoiding double-registration• De-Anonymization in case of misbehaving users• User acting as Seller/Product Owner:• Publish product-specific keys• hand Rating-Tokens to designated Raters• User acting as Rater:• use registration information and rating token to rate aspecific product

BP

Seller

RaterOutsider

7

The Basic Model - 2/2

BP

1. pp← KeyGen 2. ppk← NewProduct(Pi,prod)

3. σR ← Register 4. urt← Purchase

5. σ ← Rate(σR,prod,ppk,urt)

6. Pj ← Open(σ)7. π ← OProof(σ,Pj)

BP

f ← Verify(prod,ppk,Pi, σ)b← Link(prod,ppk,Pi, σ1, σ2)

8


BP

1. pp← KeyGen

2. ppk← NewProduct(Pi,prod)




BP


8


BP





BP


8


BP


3. σR ← Register

4. urt← Purchase



BP


8


BP





BP


8


BP




6. Pj ← Open(σ)

7. π ← OProof(σ,Pj)

BP


8


BP





BP


8

The Formal ModelWe define the ideal functionality FRS in the UC-Framework (too complex to discusshere in detail) which guarantees:

• Unforgeability of product public keys• Valid ratings guarantee• Anonymity for the rater• No Self-Ratings: the rater is not the owner of the product• Linkability: multiple ratings from the same user for the same product can bedetected (even after multiple purchases)• Traceability: the rater is registered and can be identified• Non-Frameability: no user can be accused being the author of a given rating(when the user is not the author)

9

The Formal ModelWe define the ideal functionality FRS in the UC-Framework (too complex to discusshere in detail) which guarantees:• Unforgeability of product public keys

• Valid ratings guarantee• Anonymity for the rater• No Self-Ratings: the rater is not the owner of the product• Linkability: multiple ratings from the same user for the same product can bedetected (even after multiple purchases)• Traceability: the rater is registered and can be identified• Non-Frameability: no user can be accused being the author of a given rating(when the user is not the author)

9

The Formal ModelWe define the ideal functionality FRS in the UC-Framework (too complex to discusshere in detail) which guarantees:• Unforgeability of product public keys• Valid ratings guarantee• Anonymity for the rater• No Self-Ratings: the rater is not the owner of the product• Linkability: multiple ratings from the same user for the same product can bedetected (even after multiple purchases)• Traceability: the rater is registered and can be identified

• Non-Frameability: no user can be accused being the author of a given rating(when the user is not the author)

9

The Formal ModelWe define the ideal functionality FRS in the UC-Framework (too complex to discusshere in detail) which guarantees:• Unforgeability of product public keys• Valid ratings guarantee• Anonymity for the rater• No Self-Ratings: the rater is not the owner of the product• Linkability: multiple ratings from the same user for the same product can bedetected (even after multiple purchases)• Traceability: the rater is registered and can be identified• Non-Frameability: no user can be accused being the author of a given rating(when the user is not the author)

9

Realization of FRSWe use the following techniques for our realization:

• Interactive ZK-proofs and digital signatures on committed values for Register andPurchase• Non-Interactive ZK-proofs and digital signatures for NewProduct• Signatures of Knowledge for Rate (inspired by dynamic group signatures):• proofs knowledge of registration and rating token• includes a unique element (based on rater’s identity) for linkability• can be “opened” by Identity Manager to obtain rater’s identity• Non-Interactive ZK-proofs and public-key encryption for Open and OProofFinally, we prove that our protocol UC-realizes the functionality FRS (is UC-secure).

10

Realization of FRSWe use the following techniques for our realization:• Interactive ZK-proofs and digital signatures on committed values for Register andPurchase

• Non-Interactive ZK-proofs and digital signatures for NewProduct• Signatures of Knowledge for Rate (inspired by dynamic group signatures):• proofs knowledge of registration and rating token• includes a unique element (based on rater’s identity) for linkability• can be “opened” by Identity Manager to obtain rater’s identity• Non-Interactive ZK-proofs and public-key encryption for Open and OProofFinally, we prove that our protocol UC-realizes the functionality FRS (is UC-secure).

10

Realization of FRSWe use the following techniques for our realization:• Interactive ZK-proofs and digital signatures on committed values for Register andPurchase• Non-Interactive ZK-proofs and digital signatures for NewProduct

• Signatures of Knowledge for Rate (inspired by dynamic group signatures):• proofs knowledge of registration and rating token• includes a unique element (based on rater’s identity) for linkability• can be “opened” by Identity Manager to obtain rater’s identity• Non-Interactive ZK-proofs and public-key encryption for Open and OProofFinally, we prove that our protocol UC-realizes the functionality FRS (is UC-secure).

10

Realization of FRSWe use the following techniques for our realization:• Interactive ZK-proofs and digital signatures on committed values for Register andPurchase• Non-Interactive ZK-proofs and digital signatures for NewProduct• Signatures of Knowledge for Rate (inspired by dynamic group signatures):

• proofs knowledge of registration and rating token• includes a unique element (based on rater’s identity) for linkability• can be “opened” by Identity Manager to obtain rater’s identity• Non-Interactive ZK-proofs and public-key encryption for Open and OProofFinally, we prove that our protocol UC-realizes the functionality FRS (is UC-secure).

10

Realization of FRSWe use the following techniques for our realization:• Interactive ZK-proofs and digital signatures on committed values for Register andPurchase• Non-Interactive ZK-proofs and digital signatures for NewProduct• Signatures of Knowledge for Rate (inspired by dynamic group signatures):• proofs knowledge of registration and rating token• includes a unique element (based on rater’s identity) for linkability• can be “opened” by Identity Manager to obtain rater’s identity

• Non-Interactive ZK-proofs and public-key encryption for Open and OProofFinally, we prove that our protocol UC-realizes the functionality FRS (is UC-secure).

10

Realization of FRSWe use the following techniques for our realization:• Interactive ZK-proofs and digital signatures on committed values for Register andPurchase• Non-Interactive ZK-proofs and digital signatures for NewProduct• Signatures of Knowledge for Rate (inspired by dynamic group signatures):• proofs knowledge of registration and rating token• includes a unique element (based on rater’s identity) for linkability• can be “opened” by Identity Manager to obtain rater’s identity• Non-Interactive ZK-proofs and public-key encryption for Open and OProof

Finally, we prove that our protocol UC-realizes the functionality FRS (is UC-secure).

10

Realization of FRSWe use the following techniques for our realization:• Interactive ZK-proofs and digital signatures on committed values for Register andPurchase• Non-Interactive ZK-proofs and digital signatures for NewProduct• Signatures of Knowledge for Rate (inspired by dynamic group signatures):• proofs knowledge of registration and rating token• includes a unique element (based on rater’s identity) for linkability• can be “opened” by Identity Manager to obtain rater’s identity• Non-Interactive ZK-proofs and public-key encryption for Open and OProof

Finally, we prove that our protocol UC-realizes the functionality FRS (is UC-secure).10

Future Work

Our plan for future research includes:

• Remove the trusted Identity Manager• Add attributes to ratings to make them more expressive• Realization that is secure against adaptive adversaries• Integrate revocation into the system

11

Future Work

Our plan for future research includes:• Remove the trusted Identity Manager

• Add attributes to ratings to make them more expressive• Realization that is secure against adaptive adversaries• Integrate revocation into the system

11

Future Work

Our plan for future research includes:• Remove the trusted Identity Manager• Add attributes to ratings to make them more expressive

• Realization that is secure against adaptive adversaries• Integrate revocation into the system

11

Future Work

Our plan for future research includes:• Remove the trusted Identity Manager• Add attributes to ratings to make them more expressive• Realization that is secure against adaptive adversaries

• Integrate revocation into the system

11

Future Work

Our plan for future research includes:• Remove the trusted Identity Manager• Add attributes to ratings to make them more expressive• Realization that is secure against adaptive adversaries• Integrate revocation into the system

11

Thank you very much for your attention andfeel free to ask questions!

12

SESSION ID:

#RSAC

Yu Chen

REGULARLY LOSSY FUNCTIONS AND APPLICATIONS INLEAKAGE-RESILIENT CRYPTOGRAPHY

CRYP-F03

Associate ProfessorInstitute of Information Engineering, Chinese Academy of Sciences

©Yu Chen, CAS

Regularly Lossy Functions and Applications inLeakage-Resilient Cryptography

Yu Chen1 Baodong Qin2 Haiyang Xue1

1SKLOIS, IIE, Chinese Academy of Sciences2Xi’an University of Posts and Telecommunication

CT-RSA 2018April 15, 2018

1 / 44

©Yu Chen, CAS

Outline

1 Backgrounds

2 Regularly Lossy Functions

3 Constructions of ABO RLFsConcrete ConstructionGeneric Construction

4 Applications of RLFsLeakage-Resilient OWFsLeakage-Resilient MACLeakage-Resilient CCA-secure KEM

2 / 44

©Yu Chen, CAS

Outline

1 Backgrounds




3 / 44

©Yu Chen, CAS

Lossy Trapdoor Functions

Lossy object indistinguishable from original

STOC 2008 Peikert and Waters: Lossy Trapdoor Functions and Their Applications

4 / 44

©Yu Chen, CAS

Lossy TDFs

injectiveGen(λ)→ (ek, td) X Y

fek

f−1ek

≈c

Gen(λ)→ (ek,⊥)lossy X Y

fek

2n ≫ 2τ = 2n−ℓ

5 / 44

©Yu Chen, CAS

Extension of LTFs: ABO LTFs

Gen(λ, b∗) has extra input: branch b∗ ∈ B.

Gen(λ, b∗)→ (ek, td)

. . .

fek,b1(·)fek,b2(·) fek,b∗(·)

fek,bi(·) b∗ is hidden from ek

fek,b(·) ={

lossy b = b∗

injective and invertible b = b∗

LTFs ⇔ ABO LTFs6 / 44

©Yu Chen, CAS

Constructions and Applications

(ABO)-LTF

DDH QR/DCR LWE

Homo/Dual HPS

TDF CRHF CCA PKECP-TDFATDF

OT Lossy PKED-PKE

ABM-LTF

7 / 44

©Yu Chen, CAS

Motivations

In all applications of LTF:normal mode: injective+trapdoor fulfill functionalitylossy mode: establish security

However, the full power of LTF isexpensive: large key size/high computation costoverkill: some applications (e.g., injective OWF, CRHF) do not require atrapdoor, but only normal ≈c lossy

8 / 44

©Yu Chen, CAS

A central goal in cryptography is to base cryptosystems on primtives that are asweak as possible.

Peikert and Waters conjectured “the weaker notion LF could be achieved moresimply and efficiently than LTF”.They left the investigation of this question as an interesting problem.

We are motivated to consider the following problems:

How to realize LF efficiently?Are there any other applications of LF?

Can we further weaken the notion of LF?

9 / 44

©Yu Chen, CAS

Outline

1 Backgrounds




10 / 44

©Yu Chen, CAS

A Simple But Important Observation

When trapdoor is not required for normal mode, the injective property mayalso be unnecessary.

This observation leads to our further relaxation of LFs

Regularly Lossy Functions

Intuition: the output preserves much min-entropy of input

In RLFs, functions of normal mode could also be lossy, but has to lose in aregular manner.

Definition 1f is v-to-1 (or v-regular) if maxy |f−1(y)| ≤ v.

11 / 44

©Yu Chen, CAS

Regularly Lossy Functions

normalGen(λ)→ (ek, td)

X Y

v-regular

≈c

Gen(λ)→ (ek,⊥)lossy X Y

fek

2n ≫ 2τ = 2n−ℓ

When v = 1, RLFs specialize to standard LFs12 / 44

©Yu Chen, CAS

Remarks

Why we have to choose regularity but not image size to capture normal mode?

image size is a global characterization, which only suffices to give the lowerbound of H∞(x|f(x)) by the chain rule.In contrast, regularity is a local characterization, which suffices to give thelower bound of H∞(f(x)).

The following lemma establishes the relation between the min-entropy of x andf(x):

Lemma 2Let f be a v-to-1 function and x be a random variable over the domain, we have:

H∞(f(x)) ≥ H∞(x)− log v

13 / 44

©Yu Chen, CAS

Remarks

Why we have to choose regularity but not image size to capture normal mode?image size is a global characterization, which only suffices to give the lowerbound of H∞(x|f(x)) by the chain rule.

In contrast, regularity is a local characterization, which suffices to give thelower bound of H∞(f(x)).



H∞(f(x)) ≥ H∞(x)− log v

13 / 44

©Yu Chen, CAS

Remarks

Why we have to choose regularity but not image size to capture normal mode?image size is a global characterization, which only suffices to give the lowerbound of H∞(x|f(x)) by the chain rule.In contrast, regularity is a local characterization, which suffices to give thelower bound of H∞(f(x)).



H∞(f(x)) ≥ H∞(x)− log v

13 / 44

©Yu Chen, CAS

All-But-One Regularly Lossy Functions

Gen(λ, b∗) has extra input: branch b∗ ∈ B.

Gen(λ, b∗)→ (ek, td)

. . .

fek,b1(·)fek,b2(·) fek,b∗(·)

fek,bi(·) b∗ is hidden from ek

fek,b(·) ={

lossy b = b∗

regularly lossy b = b∗

RLF ⇔ ABO-RLF14 / 44

©Yu Chen, CAS

One-Time Regularly Lossy Filters

Gen(λ)→ (ek, td)

fek,b=(bc,ba)(·)

BlossyBnormal

B = Bc ×Ba

SampLossy(td, ba)→ bc s.t. (bc, ba) ∈ Blossy

Indistinguishability: ∀ba ∈ Ba, we have:

bc ← SampLossy(td, ba) ≈c bcR←− Bc

Evasiveness: it is hard to generate a new lossy branch even given a lossybranch.

15 / 44

©Yu Chen, CAS

Relations

RLF

ABO-RLF OT-RLF

chameleon hash

ABO-RLF: the lossy branch is fixed by ek

OT-RLF: the lossy branch can be generated “on-the-fly” with td in asemi-customized manner

16 / 44

©Yu Chen, CAS

Relations

RLF

ABO-RLF OT-RLFchameleon hash

ABO-RLF: the lossy branch is fixed by ek

OT-RLF: the lossy branch can be generated “on-the-fly” with td in asemi-customized manner

16 / 44

©Yu Chen, CAS

Outline

1 Backgrounds




17 / 44

©Yu Chen, CAS

Concrete Construction from the DDH Assumption

Matrix approach for ABO-LTFs due to Peikert and Watersinput: n-dimension vector x over Z2

evaluation key: n× (n+ 1) matrix M over Goutput: xM

M =

{invertible if rank(M) = nlossy if rank(M) < n

To ensure invertible propertyinput space is restricted to {0, 1}n

line dimension m = n+ 1

For (ABO)-RLFs, we do not require invertible or even injectiveinput space extends to Zn

q

line dimension m≪ n

18 / 44

©Yu Chen, CAS

Concealer Matrix

GenConceal(n,m)→ Gn×m

1 Choose r = (r1, . . . , rn) ∈ Zp and s = (s1, . . . , sm) ∈ Zp

2 V = r⊗ s = rts3 Output C = gV ∈ Gn×m as the concealer matrix

G =

gr1s1 gr1s2 . . . gr1sm

gr2s1 gr2s2 . . . gr2sm

......

......

grns1 grns2 . . . grnsm

all columns lie in a one-dimensional subspaceC is pseudorandom under the DDH assumption

19 / 44

©Yu Chen, CAS

We construct ABO-RLF with B = Zp as below:Gen(λ, b∗): GenConceal(n,m)→ C = gV, output ek = gY = gV−b∗I′ , whereI′ = (e1, . . . , em).fek,b(x): gx(Y+bI′) = gx(V+(b−b∗)I′) ∈ Gm.

Lemma 3The above construction constitutes (pn−m, log p)-ABO-RLF.

For any b = b∗, rank(Y + bI′) = m and the size of the solution space for everyy ∈ Gm is pn−m.For b = b∗, rank(Y + bI′) = 1 and thus the image size is p.Pseudorandomness of C ⇒ hidden lossy branch

20 / 44

©Yu Chen, CAS

Extension and Comparison

Our DDH construction applies to the extended DDH, which generalize DDH, QR,DCRWe have a more efficient and direct DCR-based construction

DDH/DCR Input Lossiness Key Efficiency[PW08] 2n n− log p nm|G| nm Add

ABO-RLF pn (n− 1) log p nm|G| nm (Exp+Add)[FGK+13] N2 logN |Z∗

N3 | 1 ExpABO-LF N2/4 logN |Z∗

N2 | 1 Exp

21 / 44

©Yu Chen, CAS

Generic Construction from HPS

Wee (Eurocrypt 2012): dual HPS ⇒ LTFHPS has to satisfy strong propertyNo efficient ABO construction is known

We show HPS ⇒ ABO-RLFexploit algebra property of the underlying SMP

22 / 44

©Yu Chen, CAS

(Algebraic) Subset Membership Problem

Task: distinguish Solution: {0, 1}

X

L WRL

SampR(λ)

SampAll(λ)

SampYes(λ)

SampNo(λ)

SMP: UX ≈c UL

23 / 44

©Yu Chen, CAS

Algebraic SMPX forms an Abelian group, L forms a subgroup of XThe quotient group H = X/L is cyclic with order p = |X|/|L|

Algebraic properties ⇒ two useful facts1 Let a = aL for some a ∈ X\L be a generator of H, the co-sets

(aL, 2aL, . . . , (p− 1)aL, paL = L) constitute a partition of X.2 For each x ∈ L, ia+ x ∈ X\L for 1 ≤ i < p

24 / 44

©Yu Chen, CAS

Hash Proof SystemL ⊂ X — language defined by RL associated with SMP.HPS equips L ⊂ X with Gen, Priv, Pub.

Gen(λ)→ (pk, sk)s.t. α(sk) = pk

SK PKα (projection)

X

L

W

SampR(r)

ΠΛsk(x)

Priv(sk, x)

Pub(pk, x, w)

Projective: ∀x ∈ L, Λsk(x) is uniquely determined by x and pk ← α(sk).

25 / 44

©Yu Chen, CAS

ABO-RLF from HPS for ASMP

Let aL be a generator for H = X/L, we build ABO-RLF from HPS for ASMP asbelow:

Gen(λ, b∗): (x,w)← SampYes(λ), output ek = −b∗a+ x

fek,b(x): output α(sk)||Λsk(ek + ba)

Theorem 4Assume X = {0, 1}n and the function gx(sk) := α(sk)||Λsk(x) is v-regular for anyx /∈ L. The above construction is (v, log |Imgα|)-ABO-RLF under ASMP.

ek + ba = x+ (b− b∗)a /∈ L if b = b∗ ⇒ v-regularek + ba = x+ (b− b∗)a ∈ L if b = b∗ ⇒ lossy by the projective propertyASMP ⇒ Hidden lossy branch. For any b∗0, b

∗1 ∈ Zp:

(−b∗0a+ x) ≈c (b∗0a+ u) ≡ (b∗1a+ u) ≈c (b

∗1a+ x)

where uR←− X.

26 / 44

©Yu Chen, CAS

Leakage-Resilient Cryptography

F sk

x

F(sk, x)

Sign Dec

leakage proof

black-box

leakage prone

leakage attacks (since 1996) invalidate this idealized assumption

leak(sk)

Traditional security model assumes black-box access to cryptographic device.

28 / 44

©Yu Chen, CAS

Leakage-Resilient Cryptography

F sk

x

F(sk, x)

Sign Decleakage proof

black-box

leakage prone

leakage attacks (since 1996) invalidate this idealized assumption

leak(sk)

Traditional security model assumes black-box access to cryptographic device.

28 / 44

©Yu Chen, CAS

Bounded Leakage Model

In this work, we focus on a simple yet general leakage model called BoundedLeakage Model

F sk

gi

gi(sk)

∑|gi(sk)| ≤ |sk|

29 / 44

©Yu Chen, CAS

Leakage-Resilient OWFs

x∗R←− {0, 1}n

y∗ ← f(x∗)

(f, y∗)

gi

gi(x∗)

x x =?x∗

Theorem 5The normal mode of (1, τ)-RLFs (i.e., LFs) over domain {0, 1}n constitutes afamily of ℓ-leakage-resilient injective OWFs, for any ℓ ≤ n− τ − ω(logλ).

30 / 44

©Yu Chen, CAS

Game 0: real game1 Setup: CH generates f ← RLF.GenNormal(λ), picks x∗

R←− {0, 1}n and sends(f, y∗ = f(x∗)) to A.

2 Leakage queries: A ↪→ gi, CH responds with gi(x∗).

3 Invert: A outputs x and wins if x = x∗.

AdvA(λ) = Pr[S0]

Game 1: same as Game 0 except that:1 Setup: CH generates f ← RLF.GenLossy(λ) .

Security of RLFs ⇒ |Pr[S1]− Pr[S0]| ≤ negl(λ)In Game 1, H∞(x∗|(y∗, leak)) ≥ n− τ − ℓ.

By the parameter choice, H∞(x∗|(y∗, leak)) ≥ ω(logλ) ⇒ Pr[S1] ≤ negl(λ)even w.r.t. unbounded adversary

31 / 44

©Yu Chen, CAS

Leakage-Resilient MAC

(pp, k)← Setup(λ)pp

mi

ti ← Tag(k,mi)

gi

gi(k)

(m∗, t∗) Vefy(k,m∗, t∗) = 1(m∗, t∗) = (mi, ti)

Strong unforgeability can be relaxed in several ways:One-time: A only makes one tag queryStatic: A specifies tag queries before seeing pp

32 / 44

©Yu Chen, CAS



mi

ti ← Tag(k,mi)

gi

gi(k)


Strong unforgeability can be relaxed in several ways:

One-time: A only makes one tag queryStatic: A specifies tag queries before seeing pp

32 / 44

©Yu Chen, CAS



mi

ti ← Tag(k,mi)

gi

gi(k)


Strong unforgeability can be relaxed in several ways:One-time: A only makes one tag query

Static: A specifies tag queries before seeing pp

32 / 44

©Yu Chen, CAS



mi

ti ← Tag(k,mi)

gi

gi(k)


Strong unforgeability can be relaxed in several ways:One-time: A only makes one tag queryStatic: A specifies tag queries before seeing pp

32 / 44

©Yu Chen, CAS

Construction

Ingredient(v, τ)-ABORLF

KeyGen

ek ← ABORLF.Gen(λ, 0d)k

R←− {0, 1}n

Tagm

t← fek,m(k)

Vefy mt

t =?fek,m(k)

k - inputm - brancht - output

33 / 44

©Yu Chen, CAS

Construction

Ingredient(v, τ)-ABORLF KeyGen

ek ← ABORLF.Gen(λ, 0d)k

R←− {0, 1}n

Tagm

t← fek,m(k)

Vefy mt

t =?fek,m(k)

k - inputm - brancht - output

33 / 44

©Yu Chen, CAS

Theorem 6The above MAC is ℓ-leakage-resilient seletively one-time sUF for anyℓ ≤ n− τ − log v − ω(logλ).

Game 0: (real game)1 Setup: A↬ m∗, CH generates ek ← ABORLF.Gen(λ, 0d), picks k

R←− {0, 1}n,computes t∗ ← fek,m∗(k) and then sends (ek, t∗) to A.

2 Leakage queries: A↬ gi, CH responds with gi(k).3 Forge: A → (m, t) and wins if m = m∗ ∧ t = fek,m(k).

AdvA(λ) = Pr[S0]

34 / 44

©Yu Chen, CAS

Game 1: same as Game 0 except that1 Setup: CH generates ek ← ABORLF.Gen(λ,m∗) .

Hidden lossy branch ⇒ |Pr[S1]− Pr[S0]| ≤ negl(λ)In Game 1, A’s view includes (ek, leak, t∗). We have:

H∞(t|view) = H∞(t|ek, leak, t∗)≥ H∞(t|ek)− ℓ− τ

≥ H∞(k|ek)− log v − ℓ− τ

= n− log v − ℓ− τ

By the parameter choice, H∞(t|view) ≥ ω(logλ) ⇒ Pr[S1] ≤ negl(λ) evenw.r.t. unbounded adversary.

35 / 44

©Yu Chen, CAS

Leakage-Resilient CCA-secure KEM

(pk, sk)← Setup(λ)pk

ciki ← Decaps(sk, ci)

gi

gi(sk)(c∗, k∗0)← Encap(pk)

k∗1R←− K

βR←− {0, 1}(c∗, k∗β)

β′β′ = β

|Pr[β′ = β]− 1/2| ≤ negl(λ)

36 / 44

©Yu Chen, CAS



ci

ki ← Decaps(sk, ci)gi


k∗1R←− K

βR←− {0, 1}(c∗, k∗β)

β′β′ = β

|Pr[β′ = β]− 1/2| ≤ negl(λ)

36 / 44

©Yu Chen, CAS




gi

gi(sk)

(c∗, k∗0)← Encap(pk)k∗1

R←− K

βR←− {0, 1}(c∗, k∗β)

β′β′ = β

|Pr[β′ = β]− 1/2| ≤ negl(λ)

36 / 44

©Yu Chen, CAS

Construction

IngredientsHPS

ABORLFstrong extractor

KeyGen

(pk, sk)← HPS.Gen(λ)ek ← ABORLF.Gen(λ, 0m+d)

Encaps

(x,w)← SampYes(λ)π ← Pub(pk, x, w)

sR←− {0, 1}d

t← fek,x||s(π)k ← ext(π, s)

ek pk

c = (x, s, t)Decaps

π ← Priv(sk, x)t =?fek,x||s(π)

k ← ext(π, s) or ⊥

sk

use π to:authenticate x

derive k

37 / 44

©Yu Chen, CAS

Construction

IngredientsHPS


KeyGen


Encaps


sR←− {0, 1}d


ek pk

c = (x, s, t)

Decaps



sk


derive k

37 / 44

©Yu Chen, CAS

Construction

IngredientsHPS


KeyGen


Encaps


sR←− {0, 1}d


ek pk

c = (x, s, t)Decaps



sk


derive k

37 / 44

©Yu Chen, CAS

Theorem 7Suppose SMP for L ⊂ {0, 1}m is hard, HPS is ϵ1-universal1 and n = log(1/ϵ1),ABORLF is (v, τ)-regularly-lossy, ext is (n− τ − ℓ, κ, ϵ2)-strong extractor, then theabove KEM is ℓ-LR CCA secure for any ℓ ≤ n− τ − log v − ω(logλ).

Game 0: (real game)1 Setup: CH generates (pk, sk)← HPS.Gen(λ), ek ← ABORLF.Gen(λ, 0m+d),

sends (pk, ek) to A.2 Leakage queries ⟨gi⟩: CH responds with gi(sk).3 Challenge: CH picks β ∈ {0, 1}, s∗ ← {0, 1}d, (x∗, w∗)← SampYes(λ),

computes π∗ ← Pub(pk, x∗, w∗), t∗ ← fek,x∗||s∗(π∗), k∗0 ← ext(π∗, s∗), picks

k∗1 ← {0, 1}κ, sends c∗ = (x∗, s∗, t∗) and k∗β to A4 Decaps queries ⟨c = (x, s, t) = c∗⟩: CH computes π ← Λsk(x), output

k ← ext(π, s) if t = fek,x||s(π) and ⊥ otherwise.AdvA(λ) = Pr[S0]− 1/2

38 / 44

©Yu Chen, CAS

Game 1: CH samples (x∗, w∗) and s∗ at Setup.

Pr[S0] = Pr[S1]

Game 2: CH generates ek ← ABORLF.Gen(λ, x∗||s∗).

Hidden lossy branch ⇒ |Pr[S2]− Pr[S1]| ≤ negl(λ)

Game 3: CH computes π∗ ← Λsk(x∗) via Priv(sk, x∗).

Correctness of HPS ⇒ Pr[S3] = Pr[S2].

Game 4: CH samples x∗ via SampNo rather than SampYes.

SMP ⇒ |Pr[S4]− Pr[S3]| ≤ negl(λ)

Game 5: CH directly rejects ⟨c = (x, s, t)⟩ if x /∈ L. Define E: A makes an invalidbut well-formed decaps queries, i.e., fek,x||s(Λsk(x)) = t andx ∈ L ∧ (x, s, t) = (x∗, s∗, t∗).

|Pr[S5]− Pr[S4]| ≤ Pr[E]

39 / 44

©Yu Chen, CAS

To calculate Pr[E], it suffice to bound H∞(t|view).view: (pk, ek, leak, x∗, s∗, t∗, k∗β)

t = fek,x||s(Λsk(x))

We bound H∞(t|view) via H∞(Λsk(x)|view) as below:(x∗, s∗) determines a lossy branch ⇒ τ only reveal partial info about sk ⇒H∞(Λsk(x)|view) ≥ n− ℓ− τ − κ

We must have (x, s) = (x∗, s∗), which determines a v-regular branch ⇒H∞(t|view) ≥ H∞(Λsk(x)|view)− log v

By the parameter choice, H∞(t|view) ≥ ω(logλ), thus we have:

Pr[E] ≤ negl(λ)

40 / 44

©Yu Chen, CAS

Game 6: CH samples k∗0 ← {0, 1}κ rather than k∗0 ← ext(Λsk(x∗)). Next, we

analysis ∆[view5, view6].define view′ = (pk, ek, leak, x∗, s∗, t∗), chain rule ⇒H∞(Λsk(x

∗)|view′) ≥ n− ℓ− τ

randomness extractor ⇒ ∆[(view′, k∗5,0), (view′, k∗6,0)] ≤ ϵ2.

responses to all decaps queries in Game 5 and 6 are determined by the samefunction of (view′, k∗5,0) and (view′, k∗6,0) resp.

∆[view5, view6] ≤ ϵ2/2 ≤ negl(λ)

Putting all the above together, AdvA(λ) = negl(λ).

41 / 44

©Yu Chen, CAS

Importance

Universal1 HPS + ABO RLF ⇒ LR-CCA KEM

proper parameter choice ⇒ ℓ/|sk| = 1− o(1)

HPS ⇒ ABO-RLF

construct CCA-secure KEM with optimal leakage rate based solely onuniversal1 HPS

go beyond the upper bound posed by Dodis et al. (Asiacrypt 2010)

extend to identity-based setting as well

42 / 44

©Yu Chen, CAS

[FGK+13] David Mandell Freeman, Oded Goldreich, Eike Kiltz, Alon Rosen, and Gil Segev. Moreconstructions of lossy and correlation-secure trapdoor functions. J. Cryptology, 26(1):39–74,2013.

[PW08] Chris Peikert and Brent Waters. Lossy trapdoor functions and their applications. InProceedings of the 40th Annual ACM Symposium on Theory of Computing, STOC 2008, pages187–196. ACM, 2008.

44 / 44

session id: cryp-f03 practical, anonymous, … · session id: cryp-f03 practical, anonymous, and...

Documents