Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Compiler for Zero­Knowledge 
Proof­of­Knowledge Protocols
Diploma Thesis
November 2003 – March 2004
Prof. Dr. U. Maurer
Su...
Overview
● Motivation, Goal of the Compiler
● Input Scope
● Protocol Generation
● Output Files
● Future Work
● Conclusion
Motivation
● Anonymous credential system 
                                      ,
developed at IBM Research Laboratory in ...
Motivation
Goal of the Compiler
Input
File
Compiler
Input
File
Input
File
Java
Files
Latex
File
Part 1:  Generation of Protocol Insta...
Input Scope
● Input Language
Group G1, G2, H1, H2;
GroupElement x1, x2, x3, y1, y2;
DefineHomomorphism(zeta1, G1 x G2 ­> H...
∑­Protocol
Input Scope
Which Protocol Types are covered by the Input Scope?
∑­Protocol
Input Scope
Involved Groups
● G1 x G2 x ...
● Zm'
● Elliptic Curves, ...
● Infinite Group Z 
∑­Protocol
Input Scope
Secret
Structure
Involved Groups
● Zm'
●
 
G1 x G2 x ...
● Elliptic Curves, ...
● Infinite Group Z ...
2∑­Protocol
∑­Protocol
Input Scope
Secret
Structure
Involved Groups
● Zm'
●
 
G1 x G2 x ...
● Elliptic Curves, ...
● Infin...
∑­Protocol
2∑­Protocol
Input Scope
Secret
Structure
(y1 = 1(x1, x2)) ∨
((y2 = 2(x3)) ∧ ((y3 ,y4)= 3(x4, x5)))  
Involve...
Protocol Generation
Protocol Generation
What is hidden in this notation?
Protocol Generation
Single value 
or m­tuple?
Only one or several 
homomorphisms?
Complete challenge
or a share?
Element f...
Protocol Generation
GroupElement var8 = (GroupElement) zeta1.image(s1); 
GroupElement var9 = H.repeatedOperation(y1, c.get...
Protocol Generation
if (protocol == 2sigma) { ...
if (numberOfHomomorphisms > 1) { ...
if (numberOfPreimageGroups > 1) { ....
Protocol Generation
Measurement most widely used 
in static Software Analysis:
McCabe's 
Cyclomatic Complexity
 
CC(module...
Protocol Generation
Complexity just for the generation 
of this single comparison:  CC = 16 t = (s) yc
Cyclomatic Complex...
Protocol Generation
Protocol Structure Model
??
Protocol Generation
●  Protocol Structure Tree
comparison
join groupOp
variable
variable homomorphOp repeatedOp
...
join
v...
Generated Output Files
Different Modes for Latex Protocol Generation:
Compact Mode: Verbose Mode:
Generated Output Files
Java Classes:
public class Prover {
public class Verifier {
public Verifier(
Homorphism zeta, Group...
Future Work
● From Protocol Generation to Protocol Analysis
– Which are the properties of  these protocol 
instances, e.g....
Conclusion
● Very interesting piece of work with a strong 
connection between theoretical problems and  their 
solutions i...
You’ve finished this document.
Download and read it offline.
Upcoming SlideShare
Keynote Beamer
Next
Upcoming SlideShare
Keynote Beamer
Next
Download to read offline and view in fullscreen.

0

Share

Compiler for Zero-Knowledge Proof-of-Knowledge Protocols

Download to read offline

Zero-Knowledge Proof-of-Knowledge protocols are of particular interest for
authentication systems as developed for example in the IBM research laboratory in
Zurich. There is an arbitrary number of protocol instances that vary in terms of
protocol structure, additional restrictions on the preimages of the
homomorphisms, but also regarding the homomorphisms and groups itself that are
used. Depending on the concrete instance these protocols have
certain properties that might be useful for such systems.

The generation of a complete protocol instance for reasons of specification or
testing is a very time-consuming and error prone piece of work. Therefore this
process should be automated by the compiler that was developed during this diploma
thesis.

For this purpose an input language was created that allows to specify instances
of a certain protocol type and to add additional
types of checks using some auxiliary parameters. The user has the choice between
different levels of abstraction in specifying a certain protocol instance.

The compiler itself is written in java and is based on the traditional
object-oriented compiler design patterns. It contains in its library the basic skeleton of the
well-known Sigma protocol and of the 2Sigma protocol that was developed in the
research lab.

The compiler reads the input files with the protocol specifications written in
the input language mentioned above and checks for syntactical
correctness. Furthermore some semantic checks on the proper use of the protocol
parameters are performed. From these informations the compiler generates the
protocol instance either written as latex code or as java source code. The
latex code shows the detailed specification of the protocol instance consisting
of the documentation of the involved algebraic elements,
the facts that can be deduced in case of acceptance of the proof and all the steps performed during the
protocol execution. In case of java code generation it produces runnable java source code.
This code is based on an interface hierarchy that was developed during this
diploma thesis as well. At runtime the protocol instance has to be instantiated
with concrete implementations and can then be used for example for testing
reasons.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

Compiler for Zero-Knowledge Proof-of-Knowledge Protocols

  1. 1. Compiler for Zero­Knowledge  Proof­of­Knowledge Protocols Diploma Thesis November 2003 – March 2004 Prof. Dr. U. Maurer Supervisors: Dr. J. Camenisch, E. Bangerter IBM  Research Laboratory, Rüschlikon
  2. 2. Overview ● Motivation, Goal of the Compiler ● Input Scope ● Protocol Generation ● Output Files ● Future Work ● Conclusion
  3. 3. Motivation ● Anonymous credential system                                        , developed at IBM Research Laboratory in  Rueschlikon ● Based on Zero­Knowledge Proof­of­Knowledge  Protocols (identity mixer)
  4. 4. Motivation
  5. 5. Goal of the Compiler Input File Compiler Input File Input File Java Files Latex File Part 1:  Generation of Protocol Instances Part 2:  Derivation of Semantic Properties Semantic Properties
  6. 6. Input Scope ● Input Language Group G1, G2, H1, H2; GroupElement x1, x2, x3, y1, y2; DefineHomomorphism(zeta1, G1 x G2 ­> H1); AssignGroupMember(G1, x1); Relation =  (y1 = zeta1(x1, x2)) ∨ (y2 = zeta2(x3)); Declarations Associations Definitions Protocol  Definition
  7. 7. ∑­Protocol Input Scope Which Protocol Types are covered by the Input Scope?
  8. 8. ∑­Protocol Input Scope Involved Groups ● G1 x G2 x ... ● Zm' ● Elliptic Curves, ... ● Infinite Group Z 
  9. 9. ∑­Protocol Input Scope Secret Structure Involved Groups ● Zm' ●   G1 x G2 x ... ● Elliptic Curves, ... ● Infinite Group Z  (y1 = 1(x1, x2)) ∨ ((y2 = 2(x3)) ∧ ((y3 ,y4)= 3(x4, x5)))  
  10. 10. 2∑­Protocol ∑­Protocol Input Scope Secret Structure Involved Groups ● Zm' ●   G1 x G2 x ... ● Elliptic Curves, ... ● Infinite Group Z  (y1 = 1(x1, x2)) ∨ ((y2 = 2(x3)) ∧ ((y3 ,y4)= 3(x4, x5)))  
  11. 11. ∑­Protocol 2∑­Protocol Input Scope Secret Structure (y1 = 1(x1, x2)) ∨ ((y2 = 2(x3)) ∧ ((y3 ,y4)= 3(x4, x5)))   Involved Groups ● Zm' ●   G1 x G2 x ... ● Elliptic Curves, ... ● Infinite Group Z 
  12. 12. Protocol Generation
  13. 13. Protocol Generation What is hidden in this notation?
  14. 14. Protocol Generation Single value  or m­tuple? Only one or several  homomorphisms? Complete challenge or a share? Element from finite  or infinite group? How is the group  operation defined? Single value  or n­tuple? Single value  or m­tuple? What happens if  equation does not hold?
  15. 15. Protocol Generation GroupElement var8 = (GroupElement) zeta1.image(s1);  GroupElement var9 = H.repeatedOperation(y1, c.getValue()); GroupElement var10 =  H.operate(var8, var9);  if (!(t1.equals(var10))){ accept = false; }
  16. 16. Protocol Generation if (protocol == 2sigma) { ... if (numberOfHomomorphisms > 1) { ... if (numberOfPreimageGroups > 1) { .. if (group.isInfinite()) { ... if (output == java) { ... Naiv Implementation:
  17. 17. Protocol Generation Measurement most widely used  in static Software Analysis: McCabe's  Cyclomatic Complexity   CC(module) = number of paths through the control flow 
  18. 18. Protocol Generation Complexity just for the generation  of this single comparison:  CC = 16 t = (s) yc Cyclomatic Complexity Risk Evaluation 1 ­ 10 11 ­ 20 21 ­ 50 greater than 50 simple program, without much risk more complex, moderate risk complex, high risk untestable, very high risk  ↳ Complexity would explode
  19. 19. Protocol Generation Protocol Structure Model ??
  20. 20. Protocol Generation ●  Protocol Structure Tree comparison join groupOp variable variable homomorphOp repeatedOp ... join variable variable variable variable
  21. 21. Generated Output Files Different Modes for Latex Protocol Generation: Compact Mode: Verbose Mode:
  22. 22. Generated Output Files Java Classes: public class Prover { public class Verifier { public Verifier( Homorphism zeta, Group G, GroupElement y) { ...}  public r2param Round2(r1param) { ... } public void Round4(r3param) { ... } Implementations plugged in  at runtime ⇒ full flexibility
  23. 23. Future Work ● From Protocol Generation to Protocol Analysis – Which are the properties of  these protocol  instances, e.g. does a knowledge extractor for a  certain instance exist?
  24. 24. Conclusion ● Very interesting piece of work with a strong  connection between theoretical problems and  their  solutions in terms of software engineering ● Thanks to my supervisors for introducing me into this  area  ... and thanks for your attention

Zero-Knowledge Proof-of-Knowledge protocols are of particular interest for authentication systems as developed for example in the IBM research laboratory in Zurich. There is an arbitrary number of protocol instances that vary in terms of protocol structure, additional restrictions on the preimages of the homomorphisms, but also regarding the homomorphisms and groups itself that are used. Depending on the concrete instance these protocols have certain properties that might be useful for such systems. The generation of a complete protocol instance for reasons of specification or testing is a very time-consuming and error prone piece of work. Therefore this process should be automated by the compiler that was developed during this diploma thesis. For this purpose an input language was created that allows to specify instances of a certain protocol type and to add additional types of checks using some auxiliary parameters. The user has the choice between different levels of abstraction in specifying a certain protocol instance. The compiler itself is written in java and is based on the traditional object-oriented compiler design patterns. It contains in its library the basic skeleton of the well-known Sigma protocol and of the 2Sigma protocol that was developed in the research lab. The compiler reads the input files with the protocol specifications written in the input language mentioned above and checks for syntactical correctness. Furthermore some semantic checks on the proper use of the protocol parameters are performed. From these informations the compiler generates the protocol instance either written as latex code or as java source code. The latex code shows the detailed specification of the protocol instance consisting of the documentation of the involved algebraic elements, the facts that can be deduced in case of acceptance of the proof and all the steps performed during the protocol execution. In case of java code generation it produces runnable java source code. This code is based on an interface hierarchy that was developed during this diploma thesis as well. At runtime the protocol instance has to be instantiated with concrete implementations and can then be used for example for testing reasons.

Views

Total views

661

On Slideshare

0

From embeds

0

Number of embeds

4

Actions

Downloads

15

Shares

0

Comments

0

Likes

0

×