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
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
→ 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→ 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
→ 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
→ 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
→ Formulate an ideal functionality for reputation systems
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
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 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
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
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
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
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 - 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
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
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
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
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
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
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
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
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
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
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
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
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
2 Regularly Lossy Functions
3 Constructions of ABO RLFsConcrete ConstructionGeneric Construction
4 Applications of RLFsLeakage-Resilient OWFsLeakage-Resilient MACLeakage-Resilient CCA-secure KEM
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
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
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
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
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
2 Regularly Lossy Functions
3 Constructions of ABO RLFsConcrete ConstructionGeneric Construction
4 Applications of RLFsLeakage-Resilient OWFsLeakage-Resilient MACLeakage-Resilient CCA-secure KEM
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)).
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)).
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)).
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
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-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
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
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
2 Regularly Lossy Functions
3 Constructions of ABO RLFsConcrete ConstructionGeneric Construction
4 Applications of RLFsLeakage-Resilient OWFsLeakage-Resilient MACLeakage-Resilient CCA-secure KEM
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
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) 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
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
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
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
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
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
27 / 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 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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 query
Static: A specifies tag queries before seeing pp
32 / 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
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
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
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
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
Leakage-Resilient CCA-secure KEM
(pk, sk)← Setup(λ)pk
ci
ki ← 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
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
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
Leakage-Resilient CCA-secure KEM
(pk, sk)← Setup(λ)pk
ciki ← Decaps(sk, ci)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Top Related