S F T ’E T B U P C In partial fulfilmentupcommons.upc.edu/bitstream/handle/2099.1/24128/Analysis...

57
A NALYSIS AND P ROGRAMMING OF C RYPTOGRAPHIC S YSTEMS BASED ON E LLIPTIC C URVES AD EGREE S T HESIS S UBMITTED TO THE FACULTY OF THE E SCOLA T ÈCNICA D ’E NGINYERIA DE T ELECOMUNICACIÓ DE BARCELONA U NIVERSITAT P OLITÈCNICA DE C ATALUNYA BY D IEGO MARTÍNEZ G ILABERT In partial fulfilment of the requirements for the degree in T ELEMATIC E NGINEERING A DVISOR : J OSÉ L UIS MUÑOZ TAPIA BARCELONA ,O CTOBER 2014

Transcript of S F T ’E T B U P C In partial fulfilmentupcommons.upc.edu/bitstream/handle/2099.1/24128/Analysis...

ANALYSIS AND PROGRAMMING OFCRYPTOGRAPHIC SYSTEMS BASED ON

ELLIPTIC CURVES

A DEGREE’S THESIS

SUBMITTED TO THE FACULTY OF THE

ESCOLA TÈCNICA D’ENGINYERIA DE TELECOMUNICACIÓ DE

BARCELONA

UNIVERSITAT POLITÈCNICA DE CATALUNYA

BY

DIEGO MARTÍNEZ GILABERT

In partial fulfilmentof the requirements for the degree in

TELEMATIC ENGINEERING

ADVISOR: JOSÉ LUIS MUÑOZ TAPIA

BARCELONA, OCTOBER 2014

2

ABSTRACT

The purpose of this project is to review the current state of cryptographic systems, focusing in signatures schemesbased on elliptic curves (such as Blind Signature, Aggregate Signature or Multisignature) and to implement examples ofthese systems in Python language.

Cryptography is the practice and study of techniques for secure communication in the presence of third parties. Theuse of cryptography began thousands of years ago when classical methods of encryption were used to enhance the securityof information transmisions however currently classical cryptographic methods are obsolete in terms of security due totechnology advances, modern computers can decipher these encrypted messages in seconds.

Nowadays one of the most promising topics in Cryptography is the use of Elliptic Curves over assymetric cryptographythat allows to achive a lower key lenght with the same security properties which results as a greater strength-per-key-bit.

RESUM

El propòsit d’aquest projecte és revisar l’estat actual dels sistemes criptogràfics, centrant-se en els esquemes de sig-natures basats en corbes el·líptiques (tals com Blind Signature, Aggregate Signature o Multisignature) i implementarexemples d’aquests sistemes en llenguatge Python.

La criptografia és la pràctica i l’estudi de tècniques per assegurar les comunicacions en presència de terceres entitats.L’ús de la criptografia va començar fa milers d’anys quan els mètodes clàssics d’encriptació eren usats per millorar laseguretat de les transmissions d’informació no obstant això actualment la criptografia clàssica està obsoleta en termes deseguretat a causa dels avanços de la tecnologia, els ordinadors moderns poden desxifrar aquests missatges encriptats ensegons.

Actualment un dels camps més prometedors en Criptografia és l’ús de Corbes El·líptiques en criptografia asimètrica quepermet aconseguir una longitud menor de clau mantenint les mateixes propietats de seguretat el que resulta com una millorforça per bit de la clau.

RESUMEN

El propósito de este proyecto es revisar el estado actual de los sistemas criptográficos, centrándose en los esquemasde firmas basados en curvas elípticas (tales como Blind Signature, Aggregate Signature o Multisignature) e implementarejemplos de estos sistemas en lenguaje Python.

La criptografía es la práctica y el estudio de técnicas para asegurar las comunicaciones en presencia de terceras enti-dades. El uso de la criptografía comenzó hace miles de años cuando los métodos clásicos de encriptación eran usados paramejorar la seguridad de las transmisiones de información sin embargo actualmente la criptografía clásica está obsoleta entérminos de seguridad debido a los avances de la tecnología, los ordenadores modernos pueden descifrar estos mensajesencriptados en segundos.

Actualmente uno de los campos más prometedores en Criptografía es el uso de Curvas Elípticas en criptografía asimétricaque permite conseguir una longitud menor de clave manteniendo las mismas propiedades de seguridad lo que resulta comouna mejor fuerza por bit de la clave.

3

DEDICATORIAS

Me gustaría agradecer en primer lugar tanto a la Universitat Politècnica de Catalunya como a la Universidad MiguelHernández de Elche el haberme brindado la posibilidad de poder realizar una estancia de movilidad durante mi último añode universidad. Al igual que para otros muchos estudiantes ha supuesto un año lleno de cambios, de altibajos, de idas yvenidas; pero ante todo ha sido un año de experiencias, de nuevas sensaciones, un año que sin lugar a dudas marca unantes y un después tanto a nivel profesional como personal, un año para no olvidar nunca.

Continuar agradeciendo a la que ha sido y continua siendo mi familia en Barcelona, a los que me acogieron desde elprimer día y han sido el motivo por el que prolongue mi estancia. Lo que empezó siendo una casualidad ha acabado siendomucho más, una forma distinta de ver las cosas, otra forma de pensar. He tenido la inmensa suerte de haber encontradoalgo tan especial puesto que de alguna manera u otra todos habéis aportado a que no quiera marcharme, a que siga con lailusión de montar una fiesta de la nada, de tener nervios antes de abrir puertas y satisfacción después de desmontar en elcampus. No soy yo el primero y estoy seguro de que tampoco el último que lo dirá, pero como bien sabido és, yo exkaposeré hasta que me muera.

Momento ahora para la gente que aunque tuve que dejar atrás en busca de algo distinto, nunca me ha dado la espalda.Mil historias nos unen y mil más espero que lo hagan, ya que aunque el tiempo siga pasando seguimos siendo los mismosque éramos hace años, como niños nos conocimos y como adultos nos seguimos conociendo, algo valioso en los tiemposque corren. No necesito dar nombres aquí ni decir nada que no sepáis ya, la mayoría de los mejores recuerdos que guardoson con vosotros, gracias por ser como sois y por aguantarme ya que por muy lejos que me vaya sé que siempre os tendrécuando os necesite.

Por último pero no por ello menos importante, a mi familia. Todo lo que tengo es por vosotros y soy la persona que soy,con mis defectos y mis virtudes, gracias a ello. Por lo general no soy una persona de muchas palabras y aunque no os lodiga tanto como debería, os quiero. Siempre me habéis dado vuestro apoyo y cariño independientemente de las decisionesque tomara, siempre habéis intentado ayudarme y guiarme, siempre habéis estado tanto en los momentos alegres como enlos tristes. Gracias por todo.

Solo me queda darte las gracias también a ti, el que ahora mismo está leyendo esto. Si has llegado hasta este puntosignifica que de alguna manera u otra tú también has aportado en mi vida, de otra forma no estarías leyendo semejanteparrafada. Espero haber podido corresponderte por igual.

AGRADECIMIENTOS

Agradecer de nuevo a la Universitat Politècnica de Catalunya por el trato que me ha dado durante este curso acá-demico, a profesores, secretaría, jefa de estudios, oficina de relaciones internacionales, responsables de empresas y a todoel personal en general. No han sido pocas las consultas y visitas pero siempre he encontrado la solución a los problemasque me han ido surgiendo.

Al Departamento de Ingeniería Telemática y en especial a mi tutor de proyecto José Luis Muñoz Tapia, por haberconfiado en mi y por el apoyo que me ha brindado para la realización del mismo.

– Diego Martínez Gilabert

4

REVISION HISTORY AND APPROVAL RECORD

Revision Date Purpose

0 01/06/14 Document creation

1 09/06/14 Document revision

2 25/06/14 Documnto revision

3 09/07/14 Document revision

4 22/09/14 Document revision

6 09/10/14 Document approval

DOCUMENT DISTRIBUTION LIST

Name Email

Diego Martínez Gilabert [email protected]

José Luis Muñoz Tapia [email protected]

Written by: Diego Martínez Gilabert Approved by: José Luis Muñoz Tapia

Date: 14/10/2014 Date: 17/10/2014

Position: Project Author Position: Project Supervisor

5

6

Contents1 Introduction 11

1.1 Statement of purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.1 Requirements and specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.2 Methods and procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.3 Work plan and milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2 Symmetric and Assymetric Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Elliptic Curve Cryptography 172.1 Mathematical definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.1 Elliptic Curve properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.2 Elliptic Curve group over FP and F2m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.3 Elliptic Curve domain parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.4 Bilinear pairings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2 ECC Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.1 ECDSA - Elliptic Curve Digital Signature Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 242.2.2 ECDH – Elliptic Curve Diffie Hellman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.3 ECIES - Elliptic Curve Integrated Encryption Standard . . . . . . . . . . . . . . . . . . . . . . . 25

3 Digital Signatures 273.1 Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Multisignatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.3 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Blind Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.3 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4 Aggregate Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.3 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5 Ring Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5.3 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.6 Verifiably Encrypted Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.6.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.6.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.6.3 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.7 Group Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7

3.7.3 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Results 374.1 Multisignatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2 Blind Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3 Aggregate Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4 Ring Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.5 Verifiably Encrypted Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.6 Group Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5 Budget 49

6 Conclusions and future development 51

7 Bibliography 53

8 Glossary 57

8

List of Figures

1.1 Gantt diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1 Addition of two points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 Doubling a point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3 0 point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4 y2 = x3 − 7x over F23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5 y2 = x3 − 3x+ 5 over F23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6 y2 + xy = x3 + g4x2 + 1 over F24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

List of Tables

1.1 DH Public key protocol parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 NIST guidelines for public key sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

9

10

Chapter 1Introduction

1.1 Statement of purpose

1.1.1 Requirements and specificationsThe three main objectives that the project must accomplish are:

• Review of cryptographic conceptsIn order to introduce the topic is necessary to understand the basics of cryptograhpy focusing in the assymetriccryptograhpy and the field related with Elliptic Curves, which will be the main point of the project.

• Digital signatures schemesOnce introduced the concepts the different types of digital signatures will be explained, with their properties and thegoal that every signature tries to achieve.

• Implementation of digital signatures schemesFinally, the set of digital signatures presented will be implemented with Python Language as a example of applicationand the correctness of the schemes.

1.1.2 Methods and proceduresThis project was proposed as a new point of research in the field of cryptography and has been developed completelyusing open source software. The implementations of the digital signatures have been developed in Python language andthe present document with LATEX environment.

1.1.3 Work plan and milestones

Project: WP ref: WP1Major constituent: Software Installation 1 de 9

Short description:Installation of Linux SO v13.04, LaTeX typesetting system for the creationof the projet documentation, Okular editor and Python programming language.

Planned start date: 01/02/14

Planned end date: 15/02/14Start event: 01/02/14

End event: 15/02/14Deliverables: Dates:

11

Project: WP ref: WP2Major constituent: Review of current documentation 2 de 9

Short description:In order to achieve a required acknowledgment of cryptography and signatureschemes is necessary to review the current documentation about the topic.

Planned start date: 01/02/14

Planned end date: 21/06/14Start event: 01/02/14

End event:Deliverables: Dates:

Project: WP ref: WP3Major constituent: Review of Linux SO 3 de 9

Short description:A review of Linux SO v13.04 is necessary in order to adapt to the futurework enviroment.

Planned start date: 10/02/14

Planned end date: 24/02/14Start event: 12/02/14

End event: 22/02/14Deliverables: Dates:

Project: WP ref: WP4Major constituent: Review of Python Programming Language 4 de 9

Short description:Review of Python syntax and search of the specific libraries needed forthe project development.

Planned start date: 16/02/14

Planned end date: 16/03/14Start event: 22/02/14

End event: 19/03/14Deliverables: Dates:

12

Project: WP ref: WP5Major constituent: Review of LaTeX 5 de 9

Short description:Learning of LaTeX and its editor software Okular.

Planned start date: 16/02/14

Planned end date: 16/03/14Start event: 22/02/14

End event: 15/03/14Deliverables: Dates:

Project: WP ref: WP6Major constituent: ECC, Pairings and Signature Schemes 6 de 9

Short description:The goal is to learn the specific information required to be able toprogramm examples of each of the signature schemes presented.

Planned start date: 03/03/14

Planned end date: 21/04/14Start event: 10/03/14

End event: 28/04/14Deliverables: Dates:

Project: WP ref: WP7Major constituent: Python Programming 7 de 9

Short description:Implementation of the signature schemes introduced in last topic. presented.

Planned start date: 14/04/14

Planned end date: 09/06/14Start event: 18/04/14

End event:Deliverables: Dates:

13

Project: WP ref: WP8Major constituent: Testing of Python implementations 8 de 9

Short description:After programm the examples of the different signature schemes, we need tovalidate this implementations.

Planned start date: 10/06/14

Planned end date: 16/06/14Start event:

End event:Deliverables: Dates:

Project: WP ref: WP8Major constituent: Project Documentation 9 de 9

Short description:During the period of researching and implementation it is necesarry to keepthe documentation of the project. The documentation will be created withLaTeX typesetting editor.

Planned start date: 01/02/14

Planned end date: 20/06/14Start event:

End event:Deliverables: Dates:

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

Weeks

February March April May June

Software Installation

Review of current documentation

Review of Linux SO

Review of Python language

Learning of LaTeX Editor

ECC, Pairings and Signature Schemes

Python programming

Testing of the Python implementations

Project Documentation

Figure 1.1: Gantt diagram

Deviations

Although the project development did not suffer any substancial deviation from the work plan proposal, the TFG oralexposition was delayed due to personal issues of the author.

14

1.2 Symmetric and Assymetric CryptographyThe necessity of hide the information that we want to transmit in a way that only the person who is the receiver would beable to decipher is as older as the history about communications itself. Even in the first know civilizations we can findexamples of classic cryptography as the hieratic hieroglyphs used by the egyptian priests, the scytale employed during thewar between Athens and Sparta or the Caesar’s cipher used in the Imperial Rome times. By classic cryptography we meanthe one positioned between 4000 b.C., date of the first evidences of the use of cryptography by the egyptians, until themiddle of 20th century when there was the appearance of computers.Classical methods were generally based on the use of substitutions or transpositions over the original message modifyingthe order of appearance of the letters following a set of rules to cipher and applying the same set or rules in the oppositedirection to decipher. Although a potential intruder could have access to the message while the transmission he wouldnot be able to read the original message if he does not know which mechanism was used to cipher. Some of the mostwell-known ciphers are the Caesar Cipher (or its generalization as Affine cipher), polyalphabetic chipers as the VigenèreCipher or by substitution like the Homophonic substitution cipher.

Due to the improvement in calculus potency and the development of the mathematical models used new safer and morecomplex crytographic models appeared, the known as modern cryptographic. In 1973 one of the first points of departure ofmodern cryptography took place, the necessity of the american government to improve their computer security promotedthat the NBS (National Bureau of Standards) solicited proposals for a new cipher that should met estricted design criteria.Among all the receiverd proposals, IBM was who submitted DES (Data Encryption Standard) that under the supervisionof the NSA (National Security Agency) become the first standard in modern cryptography.DES is one of the examples of block ciphers, with a key lenght of 56 bits and a block size of 64 bits the algorithm makesan inicial permutation of the input bits and continues applying 16 rounds of a cryptographic function, finally it appliesa permutation of the output bits again. Although it has great cryptographic properties such as full dependency amongciphertext bits, and key-bits with the original message bits nowadays it is considerated as insecure due to its short keylenght, DES algorithm keys has been broken in less than 24h with the currently calculus potency.

The successor as the new cipher standard was AES (Advanced Encryption Standard), in 1997 the NIST NationalInstitute of Standards and Technology) asked for proposals to find a new successor for the already insecure DES. In 2000the Rijndael algorithm was choosen as the winner among all the proposals, it became known as AES and oficially as thenew american standard at May of 2001. AES algorithm the same as DES algorithm is a block cipher, it allows a maximumkey lenght of 256 bits and a block size of 128 bits.DES algorithm and AES algorithm keep with the classical concept of use a single key to cipher as well as decipher themessage to send, known as symmetric cryptography or secret key cryptography. The difficulties about this cryptographicmodel lie in the exchange of keys between users and the quantity of keys needed when the users group grows, if a se-cure channel is used to send the key why can not we use directly that channel to transmit the message?. The answer tothis question seems to be not so evident, but the asociate cost to the secure generation and distribution of symmetric keyswas too high for the new neccessities, the number of users was growing and the keys needed to be changed more frequently.

In parallel with symmetric cryptography in 1976 Whitfield Diffie and Martin Hellman1 revolutioned the crptographyworld bringing a new concept, asymmetric cryptography or public-key cryptography. Diffie and Hellman proposed a newmodel based on the use of a pair of keys for every user the public key (known by everyone) and the private key (knownonly by the user), this pair of keys are made in a way that anything that is ciphered with the public key of an user can bedeciphered only with his private key and anything that is ciphered with the private key of an user can be dechipered onlywith the public key of the user. This protocol solves the problem of the creation and share of a secret key between twousers over a non-secure channel as we can see in the next example:

1. Alice and Bob want to share a secret key between them over a non-secure channel.

(a) Alice: Chooses a random number a that only she knows.

(b) Bob: Chooses a random number b that only he knows.

1 Whitfield Diffie and Martin E. Hellman. (New directions in cryptography, IEEE Transactions on Information Theory) 1976.

15

2. Afterwards, they both agree into a common random number g, and:

(a) Alice: Computes ga and she sends it to Bob.

(b) Bob: Computes gb and he sends it to Alice.

3. After they receive it, then both compute:

(a) Alice: Uses their ga and b to compute gab.

(b) Bob: Uses their gb and a to compute gba.

As a result, a potential attacker would only have access to the information that has been shared through the public non-secure channel but the private keys of every user and the common shared key will remain secure.

Public Privateg aga bgb gba

Table 1.1: DH Public key protocol parameters

The security of the protocol is based over the difficulty to achieve gab = gba from ga and gb, or more precisely, to obtainthe secret keys of the users a and b solving {x = logg(g

x),∀x = a, b}. This problem is called the Discrete LogarithmProblem and is the base of the public key cryptography.

The introduction of elliptic curve cryptography by Neal Koblitz2 and Victor Miller3, independently and simultaneouslyin the mid-1980s, has yielded new public-key algorithms based on the discrete logarithm problem. Although mathemati-cally more complex, elliptic curves provide smaller key sizes and faster operations for approximately equivalent estimatedsecurity. In this work we will explain in more detail the concept of digital signature schemes based on Elliptic CurveCryptography (ECC) and the properties that they must verify.

2 Neal Koblitz. (Elliptic curve cryptosystems. Mathematics of Computation) 1987.3 Victor S. Miller. (Use of elliptic curves in cryptography) 1985.

16

Chapter 2Elliptic Curve Cryptography

After the introduction of RSA and Diffie-Hellman, researchers explored additional mathematics-based cryptographic so-lutions looking for other algorithms beyond factoring that would serve as good trapdoor functions. In 1985, cryptographicalgorithms were proposed based on an branch of mathematics called elliptic curves. Technically an elliptic curve is the setpoints satisfying an equation in two variables with degree two in one of the variables and three in the other:

y2 = x3 + a · x+ b

In Elliptic Curve cryptography the private key of the user is a random number that is used to obtain the public key of theuser one of the points (x,y) that satisfy the elliptic curve equation generated multiplying the private key with the generatorpoint G. The mathematical environment of ECC will be explained in the section 2.1 and the cryptographic systems insection 2.2.

2.1 Mathematical definition4

In general terms, a plane curve is the set of the form {(x, y) : f(x, y) = 0} where f(x, y) is a polynomial in two variablesand the degree of the curve is the total degree of f . Among the low degree plane curves we can find the lines (degree 1),the conic sections (degree 2) or the cubic curves (degree 3):

Lines ax+ by + c = 0 (2.1)

Conic sections ax2 + bxy + cy2 + dx+ ey + f = 0 (2.2)

Cubic curves a1x3 + a2x

2y + a3xy2 + a4y

3 + a5x2 + a6xy + a7y

2 + a8x+ a9y + a10 = 0 (2.3)

Elliptic curves are a certain subgroup of cubic curves defined by the equation y2 = f(x) where f(x) represents asquarefree polynomial of degree 3 which has no multiple roots.

Squarefree polynomial x3 + 1 (2.4)

Non-squarefree polynomial x3 − 3x+ 2 = (x− 1)2(x+ 2) (2.5)

If we use a cubic form, after a change of variables, the equation takes the simpler form:

E = {(x, y) : y2 = x3 + ax+ b} ∪ {0} (2.6)

4 Darrel Hankerson, Alfred Menezes, Scott Vanstone. (Guide to Elliptic Curve Cryptography) 2004

17

The definition of elliptic curve also requires that the curve be non-singular. Geometrically, this means that the graph hasno cusps, self-intersections, or isolated points. Algebraically, this involves calculating the discriminant ∆ = −16(4a3 +27b2), the curve is non-singular if and only if the discriminant is not equal to zero.

2.1.1 Elliptic Curve propertiesThe mainly operation used over ECC is the Point Multiplication where a point P on the elliptic curve is multiplied witha scalar k to obtain another point Q on the same elliptic curve.

k ∗ P = Q

For instance, if our scalar number k = 23 then we can set our point multiplication operation as:

kP = 23P = 2(2(2(2P ) + P ) + P ) + P

As a result to achive the Point Multiplication two basic operations are defined over the elliptic curve, the Point Additionof two points of the elliptic curve and the Point Doubling of a point of the elliptic curve.

• Point Addition

1. Take two points of the elliptic curve E, the points P and Q.

2. Draw the line through both points (PQ), the line will intersect E in a third point R.

3. Draw a vertical line through R that will intersect with E in a new point.

4. This new point is P +Q.

P

Q

P+Q

RE : Y2 = X3 – 5X + 8

Figure 2.1: Addition of two points

In algebraically terms the operation is denoted as:

P +Q = R or (xp, yp) + (xq, yq) = (xr, yr)

Where:

λ =yq − ypxq − xp

(2.7)

18

xr = λ2 − xp − xq (2.8)

yr = λ(xp − xr)− yp (2.9)

For example if we take {y2 = x3 − 7x} as our elliptic curve and two of their points P (−2.35,−1.86) andQ(−0.1, 0.836) we have that P +Q = R:

y2 = x3 − 7x

a = −7 | b = 0

∆ = −16(4a3 + 27b2) = 21952

λ =

yq−ypxq−xp = 1.198

xr = λ2 − xp − xq = 3.89

yr = λ(xp − xr)− yp = −5.62

R(3.89,−5.62)

• Point doubling

1. Take a point P of the elliptic curve E.2. Draw the tangent line for P over E, this line (PQ) will intersect in a new point R.3. Draw a vertical line over R until it intersects with E.4. The point where the line intersects again with E is defined as 2P .

P

2*P

R

Figure 2.2: Doubling a point

Again algebraically the operation is denoted as:

λ =3xp

2 + a

2yp(2.10)

xr = λ2 − 2xp (2.11)

yr = λ(xp − xr)− yp (2.12)

19

If now {y2 = x3 − 3x+ 5} is our elliptic curve being P (2, 2.65) one of their points then 2P = R:

y2 = x3 − 3x+ 5

a = −3 | b = 5

∆ = −16(4a3 + 27b2) = 9072

λ =

3xp2+a

2yp= 1.698

xr = λ2 − 2xp = −1.11

yr = λ(xp − xr)− yp = 2.64

R(−1.11, 2.64)

• Definition of Zero

As explained before, the point addition require that any two points that belong to the elliptic curve can be used toobtain a new point of the elliptic curve. The point P and their mirror point −P do not satisfy this rule so a newpoint is included to the elliptic curve group, the point at infinity O which is called the additive identity of the ellipticcurve.

1. Take a point P of the elliptic curve E. We denote Q as the reflected point of P . (Q = −P )

2. Draw a vertical line over Q until it intersects with E.

3. As it will not intersect again with E, we define a new point O at infinity. (P + (−P ) = 0)

Q

O

P

Q = –P

Figure 2.3: 0 point

2.1.2 Elliptic Curve group over FP and F2m

The previously properties were introduced over the real numbers field (FR) but in practice for cryptographic applicationsthe groups used are the finite fields of (FP) and (F2m ). Operations over finite fields can be computed faster which is oneof the desirable properties for a cryptographic system.

In general, a field is called a finite field if it contains only a finite number of elements where P is the size (cardinality)of the field. The elements of (FP) are the integers in the set {1, 2, 3, . . . , p−1} where p is an odd integer and the operationsof addition and multiplication are modular.

y2 mod p = x3 + ax+ b mod p

20

We define the same operations than over R but in this case over FP:

• Point Addition

λ =yq−ypxq−xp mod p

xr = λ2 − xp − xq mod p

yr = λ(xp − xr)− yp mod p

• Point Doubling

λ =yq−ypxq−xp mod p

xr = λ2 − xp − xq mod p

yr = λ(xp − xr)− yp mod p

If we take now the curves used for the last examples over F23 we can see that there are 23 points that satisfy the equation:

Figure 2.4: y2 = x3 − 7x over F23 Figure 2.5: y2 = x3 − 3x+ 5 over F23

S It is relevant to point out that over the field FP all the solutions to the elliptic curve have a positive value since thenegative components in the y-values are taken module FP being in consequence a positive number. After the graphs wecan note how it is not clear the symmetry or even the geometry of the elliptic curve due to the it is reduced just to a fewdiscrete points.

The binary field F2m is a finite field of order 2m where their elements are polynomials whose coefficients are in thefield F2 = {0, 1} of degree at most m− 1:

F2m = {am−1zm−1 + am−2zm−2 + · · ·+ a2z

2 + a1z + a0 : ai ∈ {0, 1}}

If we take the binary field F24 their 16 binary polynomials of degree at most 3 are:

0 z2 z3 z3 + z2

1 z2 + 1 z3 + 1 z3 + z2 + 1z z2 + z z3 + z z3 + z2 + z

z + 1 z2 + z + 1 z3 + z + 1 z3 + z2 + z + 1

A elliptic curve over F2m is formed by choosing the elements a and b within the field domain and includes all the pointsthat satisfy the curve equation over F2m together with the point at infinity:

y2 + xy = x3 + ax2 + b

21

Again, we define the same operations than over R but in this case over F2m :

• Point Addition

λ =yp−yqxp+xq

xr = λ2 + λ+ xp + xq + a

yr = λ(xp + xr) + xryp

• Point Doubling

λ = xp +ypxp

xr = λ2 + λ+ a

yr = xp2 + (λ+ 1)xr

For our example we will take y2 + xy = x3 + g4x2 + 1 as our elliptic curve over the field F24 with the irreduciblepolynomial f(x) = x4 + x+ 1. There are fifteen points that satisfy this equation:

Figure 2.6: y2 + xy = x3 + g4x2 + 1 over F24

2.1.3 Elliptic Curve domain parameters

In order to define completely the elliptic curve environment is necessary to set a n-tuple of parameters for both the finitefields of FP and F2m .

EC domain parameters for FP

The domain parameters are the 6-tuple formed by {p,a,b,G,n,h} where:

• p: The cardinality of the field, an integer that define the maximum value of the points of the elliptic curver over thefinite field.

• a, b: The coefficients of the elliptic curve E(FP ) defined by E:y2 mod p = x3 + ax+ b mod p

• G: The generator point G = (Gx, Gy) on E(FP ) of the elliptic curve

• n: Primer number that denotes de order of the generator point G.

• h: The cofactor #E(FP )/n.

22

EC domain parameters for F2m

The domain parameters are the 7-tuple formed by {m, f(x),a,b,G,n,h} where:

• m: The extension degree of the finite field F2m .

• f(x): The irreducible binary polynomial of degree m that cannot be factored as a product of binary polynomials eachof degree less than m.

• a, b: The coefficients of the elliptic curve E(F2m ) defined by E:y2 + xy = x3 + ax2 + b.

• G: The generator point G = (Gx, Gy) on E(F2m ) of the elliptic curve

• n: Primer number that denotes de order of the generator point G.

• h: The cofactor #E(F2m)/n.

2.1.4 Bilinear pairings5

The pairing-based cryptography is the use of a pairing between elements of two cryptographic groups to a third group toconstruct cryptographic systems, pairings have been used to construct many cryptographic systems for which there is noother efficient implementation.

The major pairing-based construct is the bilinear map, considering two groups G1 as a subgroup of the additive groupof points of an elliptic curve #E(FP ) and G2 as a subgroup of the multiplicative group of a finite field #E(F∗P 2) then wecan consider the mapping e as follow:

e : G1 ×G1 → G2

• BilinearityThe map e : G1 ×G1 → G2 is considered bilinear if {∀P,Q ∈ G1∀ ; a, b ∈ Z∗q}:

e(aP, bQ) = e(P,Q)ab (2.13)

• Non-degenerateThe map e : G1 ×G1 → G2 does not send all the pairs to the identity in G2, it means that {∀P ∈ G1 , P 6= 0}:

e(P, P ) = G2 ∧ e(P, P ) 6= 1 (2.14)

If P is the generator point of the group G1 then is also the generator point of the group G2.

• ComputableThere is an efficient algorithm to compute e(P,Q) {∀P,Q ∈ G1}.

2.2 ECC Cryptography6

The theory of elliptic curve has been studied purely in the mathematical field for more than 160 years, it was not until1980’s when Miller and Koblitz independently found that the group of points on a elliptic curve is a proper group on whichthe discrete logarithm is tractable and suitable for implementing cryptographic systems. The mathematical basis for thesecurity of ECC is the computational intractability of the Elliptic Curve Discrete Logarithm Problem (ECDLP). The mainproblem of conventional public key cryptography systems is that the key size has to be large enough in order to meet thesecurity requirements, however, since the ECDLP appears to be significally harder than DLP the strength-per-key-bit issubstantially greater in ECC which results in higher system speed and lower consumption of resources.

5 Ben Adida. (Pairing-Based Cryptography) 20046 Certicom. (An Elliptic Curve Cryptography (ECC) Primer) 2004

23

ECC Key Size RSA Key Size Key Size Ratio AES Key Size(Bits) (Bits) (Bits) (Bits)163 1024 1 : 6256 3072 1 : 12 128384 7680 1 : 20 192512 15360 1 : 30 256

Table 2.1: NIST guidelines for public key sizes

2.2.1 ECDSA - Elliptic Curve Digital Signature Algorithm7

The ECDSA is a variant of the Digital Signature Algorithm (DSA) implemented over Elliptic Curves and the discretelogarithm.

• Signature Generation AlgorithmFirst of all we need to set the key par of the user as:

1. Choose the elliptic curve E with generator point G of order n and select one of their points P .

2. Choose randomly a number between the interval [1, n− 1] and compute Q = dP .

3. The private key of the user is d meanwhile the public key is Q.

If a user wants to sign a message he needs to:

1. Choose a random number k.

2. Compute kP = (x1, y1) and set r = x1 mod n. If r = 0 then return to the first step.

3. Compute s = k−1(H(m) + rd) mod n. If s = 0 return to the first step.

4. The signature is the pair (r, s).

• Signature Verification AlgorithmTo verificate the signature of a message then we need to:

1. Check that r and s belong to the interval [1, n− 1].

2. Compute w = s−1 mod n.

3. Compute u1 = H(m)w mod n. and u2 = rw mod n.

4. Set (x0, y0) = u1 × P + u2 ×Q.

5. The signature is verified only if r = x0 mod n since:

r = u1 × P + u2 ×Q → r = u1 × P + u2d× P → r = (u1 + u2d)× P

r = (u1 + u2d)× P → r = (H(m)s−1 + rds−1)× P → r = (H(m) + rd)s−1 × P

r = (H(m) + rd)(H(m) + rd)−1(k−1)−1 × P → r = k × P

r = x1 mod n (2.15)

7 Don Johnson, Alfred Menezes, Scott Vanstone. (The Elliptic Curve Digital Signature Algorithm) 2001

24

2.2.2 ECDH – Elliptic Curve Diffie Hellman8

The ECDH is a key secure exchange algorithm that it is used over non secure channels to establish a shared secret asexplained in section 1.2. Let be the domain parameters {p, a, b,G ,n, h} (section 2.1.3) and the public and private keypair of the users (dA, QA) and (dB , QB) then:

1. User A computes (xk, yk) = dAQB .

2. User B computes (xk, yk) = dBQA.

3. The shared secret calculated by both parts are equal since:

dAQB = dAdBG = dBdAG = dBQA

Meanwhile the secret keys of the users are still private, the only information that is reveal is the public keys of users A andB which is not enough to compute the shared secret key (xk, yk).

2.2.3 ECIES - Elliptic Curve Integrated Encryption Standard9

The ECIES is a scheme based on the Diffie-Hellman problem and a variant of the ElGamal public encryption scheme thatprovides message confidenciality and integrity using a Key Derivation Function (KDF) a Message Authentication Code(MAC) and a symmetric scheme E where the domain parameters are {p, a, b,G ,n, h} (section 2.1.3) and the public andprivate key pair of the users (dA, QA) and (dB , QB).

In ECIES a Diffie-Hellman shared secret is used to derive the symmetric keys k1, used to encrypt the plaintext using asymmetric scheme, and k2 to authenticate the resulting ciphertextto encrypt a message:

1. Generate a random number r ∈ [1, n− 1] and compute R = rG.

2. Derive a shared secret S = Px where P = (Px, Py) = rQB and P 6= 0.

3. Use KDF to derive a symmetric encryption and a MAC key

kE ||kM = KDF (S||S1)

4. Encrypt the message c = E(kE ;m).

5. Compute the tag of encrypted message and S2:

d = MAC(KM ; c||S2)

6. Output R||c||d.

Then to decrypt the ciphertext R||c||d:

1. Derive the shared secret S = Px where P = (Px, Py) = RdB and output failed if (P = 0).

2. Derive the keys as kE ||kM = KDF (S||S1).

3. Use MAC to check the tag and output failed if d 6= MAC(KM ; c||S2)

4. Use symmetric encryption scheme to decrypt the message m = E−1(kE ; c).

8 D. McGrew, K. Igoe, M. Salter. (Fundamental Elliptic Curve Cryptography Algorithms) 20119 Jose L. Muñoz (Asymmetric Algorithms) 2012

25

26

Chapter 3Digital Signatures

3.1 Digital Signatures

Digital signatures schemes are designed to provide the digital counterpart to handwritten signatures, a digital signaturemust be dependant of some secret known only by the signer and additionally by the content of the message being signed.Moreover, they should provide of the following cryptographic properties:

• Confidenciality. The information only can be known by authorized people.

• Integrity. The information must stay unchanged unless it is modified by authorized people.

• Authentication. The information is valid and its origin is validated.

• Non-repudiation. The assurance that an entity cannot deny previous actions or commitments.

A signature scheme is said to be secure if it is existentially unforgeable by a computationally bounded adversary who canamount an adaptative chosen-message attack. In general terms a signature scheme consists on a set of three algorithms:

1. A Key Generation Algorithm that takes as input the domain parameters of the system and outputs the key pairs(sk, pk).

2. A Signature Generation Algorithm that produces a signature σ from the message m and the private key sk.

3. A Signature Verification Algorithm that takes as input the signature σ and the message m and accepts or rejectsthe signature.

As previously said the assymetric cryptography solves the problem of the key share over a non-secure channel but it isa slower method in comparison with the symmetric crytography, therefore, in practice we use a fast method to cipher(symmetric cryptography) and a secure method to share the keys (assymetric cryptography). For instance, if we comeback to the scenario of Alice and Bob suppose that now Alice wants to send a message to Bob and sign it, the usualprocedure to create a digital signature of the message would be:

• Alice ciphers the message using a symmetric key and uses the public key of Bob to cipher as well the symmetrickey.

• Bob receives the encrypted message symmetric key, he uses his private key to obtain the symmetric key and thendecipher the message.

27

3.2 MultisignaturesMultisignature schemes are digital signature schemes that represent a certain number of signers signing a given message insuch a way that the document signature is valid if and only if all and every single member of the group signs the documentand each signature can be correctly verified, that is, the signers identities must be evident from the given multisignature.

A first intuitive solution to this problem would be the concatenation of the different signatures generated of the signersinto an unique singular sign, however, the signature lenght would grow linearly with the number of signers in the subgroupand also could be a hint to a potential attacker about the number of signers. Therefore the lenght of the multisignaturemust be equal as one of the initial signer keys.

3.2.1 Properties• The multisignature can be verified at once instead of verify every public key of every user.

• Size of the subgroup can be arbitrary but the lenght of the multisignature must be fixed independently of the numberof users.

• The identities of all the signers must be public.

3.2.2 Related Work• 1986: Itakura and Nakamura (A public key cryptosystem suitable for digital multisignatures).

• 1988: Okamoto (A digital multisignature shceme using bijective public-key cryptosystems).

• 1989: Harn and Kiesler (Group oriented (t,n) threshold digital signature shceme and digital multisignature).

• 1991: Ohta and Okamoto (A digital multisignature scheme based on the Fiat-Shamir shcheme).

• 1999: Ohta and Okamoto (Multisignature scheme secure against active insider attacks).

• 2002: Boldyrva (A efficient threshold signature, multisignature and blind signature schemes based on the Gap-Diffie-Hellman-group signature scheme).

3.2.3 Scheme10

• Key Generation

Given the global information:I = (p, g,H)

Set Sk as the private key of the user:Sk = x ∈ Zp∗

And Pk as the public key of the user:Pk = gx

• Multisignature creation

Any user that wishes to participate in the signing process computes:

σj = H(m)xj

10 Alexandra Boldyrva. (Efficient threshold signature, multisignature and blind signature schemes based on the Gap-Diffie-Hellman-group signaturescheme)

28

Being L = {Pi1 , . . . , Pil} the players than contribute to signing, J = {i1, . . . , il} the indeces of such players andPj ∈ P the players:

σ =∏j∈J

(σj)

And outputs:T = (M,L, σ)

• Multisignature verification

Given T = (M,L, σ), and (Pki1 , . . . , Pkil ) compute:

PkL =∏j∈J

(Pkj ) =∏j∈J

(gxj )

And verify:e(g, σ) = e(PkL , H(m))

3.3 Blind SignaturesBlind signatures are a form of digital signature in which the content of a message is blinded before it is signed. The maingoal is on the one hand to let the user obtain a signature without allowing the signer to acknowledge the message contentand on the other hand do not let to obtain more than one signature from the signer to the user. Typically used in digitalcash schemes the resulting blind signature can be publicly verified against the original unblinded message in the mannerof a regular digital signature.

3.3.1 Properties• Used when user’s privacy is primary.

• Content of the message is blinded before it is signed.

• Signature scheme should guarantee that it is difficult for the user to forge a signature of any additional document,even after getting from the bank a number of blind signatures.

3.3.2 Related Work• 1982: Chaum (Blind signatures for untreacceable payments).

• 2001: Bellare et al (The One-More-RSA Invertion problems and the security of Chaum’s Blind Signature Scheme).

3.3.3 Scheme11

• Key Generation

Set Sk as the private key of the signer:Sk = x ∈ Zp∗

And Pk as the public key of the signer:Pk = x · P

11 Alexandra Boldyrva. (Efficient threshold signature, multisignature and blind signature schemes based on the Gap-Diffie-Hellman-group signaturescheme)

29

• Blind signature creationBlinding of the message, the user chooses a random number from to Z∗p and make the hash of the message:

r ∈ Zp∗ → M ′ = r ·H(m)

Signing of the message, the signer computes and sends it back to the user:

σ′ = x ·M ′

Unbinding of the message, the user computes:σ = r−1 · σ′

• Blind signature verificationGiven a public key Pk, a message m and a signature σ verify:

e(Pk, H(m)) = e(P, σ)

3.4 Aggregate SignaturesAn aggregate signature scheme is a digital signature that supports aggregation, given n signatures on a n distinct messagesfrom n distinct users, it is possible to aggregate all these signatures into a single short signature. The aggregate signature(and the n original messages) will convince the verifier that the n users did indeed sign the n original messages.

3.4.1 Properties• The lenght of the aggregate signature must be the same of any of the individual signatures.

• Allows scalability since the size of the signature does not increase with the number of users.

3.4.2 Related Work• 2002: Alexandra Boldyrva (Efficient threshold signature, multisignature and blind signature schemes based on the

Gap-Diffie-Hellman-group signature scheme)

• 2003: Boneh, Gentry, Lynn and Shacham (Aggregate and verifiably encrypted signatures from bilinear maps).

3.4.3 Scheme12

• Key GenerationSet Sk as the private key of the user:

Sk = x ∈ Zp∗

And Pk as the public key of the user:Pk = gx2

• Aggregate signature creationCompute:

h = H(m)

And then set the signature of each user:σ = hx

That can be verificated as:e(σ, g2) = e(h, Pk)

12 Boneh, Gentry, Lynn and Shacham. (Aggregate and verifiably encrypted signatures from bilinear maps)

30

• Aggregate signature aggregation

Each user Ui ∈ U provides a signature σi ∈ G1 on a message Mi ∈ {0, 1}∗ and then compute the aggregatesignature as:

σ =

k∏i=1

σi

• Aggregate signature verification

Given an user’s signature σ ∈ G1, the messages Mi ∈ {0, 1}∗ (all must be different between them) and the publickeys Pki ∈ G2 compute:

hi = H(mi)

And accept if:

e(σ, g2) =

k∏i=1

e(hi, Pki)

3.5 Ring Signatures

Consider a set of users each having a public/private key par, ring signature on U is a signature that is constructed usign allthese public keys of the users in U and a single private key of any user in U. The signer does not need the knowledge orconsent of the other ring members to put them in the signature which is the main difference with group signatures.

3.5.1 Properties

• A verifier is convinced that the signature was produced using one of the private keys of U but he is not able todetermine which one.

• Different members can use different public key signature schemes with different sizes and keys.

• Allows to specify a set of possible signers without revealing which member actually produced the signature.

3.5.2 Related Work

• 2001: Rivest, Shamir and Tauman (How to leak a secret).

• 2002: Naor (Deniable ring authentication).

• 2002: E. Bresson, J. Stern and MSzydlo (Threshold ring signatures and applications to ad-hoc groups).

3.5.3 Scheme13

• Key Generation

Set Sk as the private key of the user:Sk = x ∈ Zp∗

And Pk as the public key of the user:Pk = gx2

13 Boneh, Gentry, Lynn and Shacham. (Aggregate and verifiably encrypted signatures from bilinear maps)

31

• Ring signature creationGiven Pki = (Pk1 , . . . , PKn) the public keys of the users,M ∈ {0, 1}∗ the message, Sk the private key of the signerand ai = (a1, . . . , an) ∈ Zp a random number choosen for every user, compute:

σs =

(h

ψ(∏i 6=s Pkai )

)1/x

∀i 6= s | σi = gai2

• Ring signature verificationGiven the public keys Pki = Pk1 , . . . , Pkn , the message M ∈ {0, 1}∗ and the ring signature compute:

h = H(m)

And verify:

e(g1, h) =

n∏i=1

e(Pki , σi)

3.6 Verifiably Encrypted SignaturesThe bilinear verifiably encrypted signature scheme is built on the bilinear aggregate signature scheme, the signer encryptsits signature under the public key of a trusted third party (the adjudicator) and proves that this value contains a validsignature.

3.6.1 Properties• No involment of adjudicator during generation of encrypted signature or verification, only involves during signature

phase.

• Usually used in contract-signing protocols.

3.6.2 Related Work• 2003: Boneh, Gentry, Lynn and Shacham (Aggregate and verifiably encrypted signatures from bilinear maps).

• 2012: Steve Lu, Rafail Ostrovsky and Amit Sahai et al (Sequential Aggregate Signatures, Multisignatures, andVerifiably Encrypted SignaturesWithout Random Oracles).

3.6.3 Scheme14

• Key GenerationThe private/public key par of the signer is:

(x, gx2 )

Meanwhile the private/public key par of the adjudicator is:

(x′, gx′

2 )

And the signature of the message and the verification are respectively:

σ = H(m)x ∈ G1

e(g2, σ) = e(gx2 , H(m))

14 Boneh, Gentry, Lynn and Shacham. (Aggregate and verifiably encrypted signatures from bilinear maps)

32

• Verifiably Encrypted signature creation

Given a secret key x ∈ Z∗p, the message m ε {0, 1} and the public key of the adjudicator v′ = gx2′ compute:

h = H(m) → σ = hx

Then choose a random r ε Z∗p and set:µ = ψ(g2)r

σ′ = ψ(v′)r

Where the output is:(σ · σ′, µ) → (ω, µ)

• Verifiably Encrypted signature verification

Given v = gx2 the public key of the user, m ∈, {0, 1}∗ the message and v′ = gx2′ the public key of adjudicator,

compute:h = H(m)

And accept if:e(ω, g2) = e(h, v) · e(µ, v′)

Since:e(h, v) · e(µ, v′) = e(H(m), gx2 ) · e(gr2, gx

2 ) = e(H(m)x · (gx′

2 )r, g2)

e(σ · (v′)r, g2) = e(σ · σ′, g2) = e(ω, g2)

• Adjudication

Given the public key of the user v = gx2 , the message m ∈ {0, 1}∗, the public key of adjudicator v′ = gx2′ and the

output (ω, µ) compute to ensure that the veriafibly encrypted signature is valid:

σ =ω

µx′

Before giving the signature σ, the adjudicator must perform the validity test to prevent a malicious user from trickinghim into signing arbitrary messages under adjudication key.

3.7 Group SignaturesA group signature scheme is a method for allowing a member of a group to anonymously sign a message on behalf of thegroup. Essentially a group signature scheme is a group manager, who is in charge of adding group members and has theability to reveal the original signer in the event of disputes

3.7.1 Properties• Only members of the group can sign messages.

• The receiver of the signature can verify that it is a valid signature of that group, but cannot discover which memberof the group made it.

• In case of dispute later on, the signature can be "openend" (with or without the help or the group members) to revealthe identity of the signer.

33

3.7.2 Related Work• 1991: David Chaum, Eugène van Heyst (Group signatures).

3.7.3 Scheme15

• Key GenerationThe key generation algorithm takes as input n, the number of user keys to generate and it proceeds as follows:

1. Select a generator g2 in G2 uniformly at random and set g1 ← ψ(g2)

2. Select γ ← Zp and set w = gγ2 .

3. Select ξ1, ξ2 ← Zp and set u, v ∈ G1 such that uξ1 = vξ2 = h.

4. Using γ generate for each user an SDH tuple (Ai, xi by selecting xi ← Zp such that γ + xi 6= 0), and settingAi ← g

1/γ+xi1 .

The group public key is gpk = (g1, g2, h, u, v, w). The private key of the group manager is gmsk = (ξ1, ξ2). Eachuser’s private key is its tuple gsk[i] = (Ai, xi). The revocation token corresponding to a user’s key (Ai, xi) isgrt[i] = Ai. The algorithm outputs (gpk, gsk, grt). The private key γ is only known by the issuer.

• Group signature creationThe signing algorithm takes as input a public key gpk = (g1, g2, h, u, v, w), a user private key gsk[i] = (Ai, xi)and a message M ∈ {0, 1}∗ and proceeds as follows:

1. Pick random values α, β ← Zp and compute a linear encryption of Ai:

T1 = uα T2 = vβ T3 = Ai · hα+β

and compute also the variables:δ1 = x · α δ2 = x · β

2. Pick blinding values rα, rβ , rx, rδ1 , rδ2 ← Zp and compute the values R1, R2, R3, R4 and R5 as:

R1 ← urα R2 ← vrβ

R3 ← e(T3, g2)rx · e(h,w)−rα−rβ · e(h, g2)−rδ1−rδ2

R4 ← T rx1 · u−rδ1 R5 ← T rx2 · u−rδ2

3. Compute a challenge value c ∈ Zp using H:

c← H(M,T1, T2, T3, R1, R2, R3, R4, R5) ∈ Zp

4. Compute the values sα, sβ , sx, sδ1 and sδ2 ← Zp as:

sα = rα + cα sβ = rβ + cβ sx = rx + cx sδ1 = rδ1 + cδ1 sδ2 = rδ2 + cδ2

And outputs the signature σ ← (T1, T2, T3, c, sα, sβ , sx, sδ1 , sδ2).

15 David Chaum, Eugène van Heyst. (Group signatures)

34

• Group signature verificationThe verification algorithm takes as input a group public key gpk = (g1, g2, h, u, v, w), a set RL of revocation tokens(each an element of G1), a purpoted signature σ = (r, T1, T2, c, sα, sx, sδ) and a message M ∈ {0, 1}∗ to proceedin two phases. First, it ensures that the signature σ is valid; then it ensures that σ was not generated by a revokeruser and accepts only if both conditions hold.

– Signature check1. Re-derive R1, R2, R3, R4 and R5 as:

R1 ← usα · T−c1 R2 ← vsβ · T−c2

R3 ← e(T3, g2)sx · e(h,w)−sα−sβ · e(h, g2)−sδ1−sδ2

R4 ← T sx1 · u−sδ1 R5 ← T sx2 · u−sδ2

2. Check that the challenge c is correct:

c← H(M,T1, T2, T3, R1, R2, R3, R4, R5) ∈ Zp

Only if the signature verification matches accept, otherwise reject the signature.

– Verification checkFor each element A ∈ RL (Revocation List) check whether A is encoded in (T1, T2, T3) by checking if:

e(T3/A, u) = e((T1 · T2)ξ1 , v)

If no element of RL is encoded in (T1, T2, T3), the signer of σ has not been revoked

Finally the algoritm outputs valid if both phases accept or invalid otherwise.

• Group signature openingThis algorithm is used by the group manager to trace a signature to the signer. It takes as input a group public keygpk = (g1, g2, h, u, v, w), the corresponding private key of the manager gmsk = (ξ1, ξ2) together with a messageM and a signature σ ← (T1, T2, T3, c, sα, sβ , sx, sδ1 , sδ2). and proceeds as:

1. Considering the three elements of the linear encryption (T1, T2, T3) recover the signer Ai as:

Ai =T3

T ξ11 · Tξ22

2. Check which public key of the group matches with {Ai = Ai, ∀i : 1 < i < n}:

{Ai = Ai} → user i is the signer

35

36

Chapter 4Results

4.1 MultisignaturesImplementation of the scheme explained in section 3.2 where in a group of four users three of them decide to create acommon multisignature using their own signatures. The receiver can verify the correctness of the signature using thepublic keys of the users that took part in the signing process and the message received.

• The multisignature can be verified at once instead of verify every public key of every user.

• Size of the subgroup can be arbitrary but the lenght of the multisignature must be fixed independently of the numberof users.

• The identities of all the signers must be public.

groupType: SS512groupOrder: 730750818665451621361119245571504901405976559617

g:[6765428367341340224259967516457196648695158200161692559718134186267362156721345616595433494102235943111159973391433848531063345540489371951816487637988840, 6095714608302068351131766184802094545774844852461938029768045420695988858026717029668416398003535989723679172507158676032121940810187394994944088751196087]

Message: Sample text for multisignature exampleL: [1, 1, 0, 1]

### User 1sk: 361449818947376558664698420057458956771117821507pk:[1598624470639569013694308007583205183589335209759456225736409102032701393739425553582201042204247095535327539159731788804299823790318484384593751002898629, 7358933224619057103923392613991355873439561983511961089190281960353843264213647982792424371931368613058952174844737419440370958091732866124430768527207623]σ :[6413778495956448757279966367843852641690828522797492707414653096302376962374832344880129467649096165647831168484133292962317416739554308501917496388461346, 3128125159874995911331884747272251722331924748969008885580481293326281719548814479694532771195013335917987797067981327995243172020374016192223962156403629]

37

### User 2sk: 13377431896900169439488509961765697702910186195pk:[4975984152544373552845067361372248962154241691518804881651013629558051364231829743300200448077510695926671001228398354256597688208694115732738279856883331, 803993482520533508847407856899161906524540923767819848152879979421865206974329572357883306489536381392605509713781638904085875894106188007410089050497830]σ :[352728563863975524593694029596883056193131849208483516476964069919668619321284164734463432893455788548743559353337466676847490974334818296648840324587473, 7428623474000406809740553062408198357737706774341598815043000844358518807969925199535963793412770572457102272395762085556245951482321745186582319831909628]

### User 3sk: 629700982036517440103722195099967650979458085626pk:[2582028432128169997840209460261736364165250292020025258959946375338860001527264055810798185401152712400072850312601632471275343874983857303409020584151858, 3716752465546257875373906035562070016670946946427048106821274356962136160706628800486190477571255427675489025379595595088273494446678078751809808487655144]σ : –

### User 4sk: 406008808597937601092107803714229736501999992657pk:[6323260846458208014336396026704727996276259512074619776188903735881594784561424784481330295402663558568935809148789280473294827390308953840869773884595978, 7605960157130803754419753575296600151105879072581526776754338760701686586897556494301122451942931883209394850136594622463111565475331235553515471827140253]σ :[344076841817916595953864550328405186528920373866518679148364856480126842614625252051532532732338492268362821010432546526428166067839127187740658676325159, 874486727314154853046610049974594419976776899600995248002730403167454965831064859996163969178641154403577669153948629663019845118203032120672992091803090]

Multisignature: [8579032735819921957747809390007785581718496172272319779742636035662183850482790529845286750659461402629238554244521839414631351309681611187139976792619355, 3803786039428749741017560886760124283550556549785478730312938986570297756957345992332123669153837078255853590916410609190298437740871215841373109763460081]

e(g, σ) : 183325351077381669902815745240080705305915247660

e(PkL , H(m)) : 183325351077381669902815745240080705305915247660

4.2 Blind SignaturesImplementation of the scheme explained in section 3.3 where a user chooses a random number r to blind the message M ,then the signer using his private key signs the blinded message and sends it back to the user. A third party can verify thecorrectness with the public key of the signer Pk, the message M and the signature σ.

• Used when user’s privacy is primary.

• Content of the message is blinded before it is signed.

38

• Signature scheme should guarantee that it is difficult for the user to forge a signature of any additional document,even after getting from the bank a number of blind signatures.

groupType: SS512groupOrder: 730750818665451621361119245571504901405976559617

g:[6827171484314947886722132836094407090687941048330084891643663037288438952985494944452508884151676869691897554562311237052153673415873665478187212808192045, 1263275073947450570462147787011413015250775614783657185751548734931175284822833019338396537163541026542108585186944508802010255220404369595681644080758559]

sk: 73507176391973992643111499177357536223983334966pk:[4840434514273177804111037625761839311708515921130777798296160476809792438068134036172916127478985016765372470850288251364572087225336298647484260122663393, 2365256670904102095859043575265711037957343212790001005471895839113562286783991405547372097223905062595912934084222974419841670054963583977878790330124112]

Message: Example message for Blind Signature

r: 416497526491767719357708311103670335227903708113

Blind Signature:[2022244051877553649394454760546655524439076184310348093304809757372381182155273433637529857426073360259345324374197501949059536169578535613781855568165293, 948644683340417186134527545924766439250404256993726220049023872090133182513775092084923568723692571696743973763849655107942369257577168729143492771702456]

e(Pk,H(m)) : 128429421794567125931589732120343895954151855300

e(g, σ) : 128429421794567125931589732120343895954151855300

4.3 Aggregate SignaturesImplementation of the scheme explained in section 3.4 where a set of three users with their own three different messagesdecide to create a single short signature that represents the whole group of users with their corresponding messages thatcan be verified by a third party using public information.

• The lenght of the aggregate signature must be the same of any of the individual signatures.

• Allows scalability since the size of the signature does not increase with the number of users.

groupType: SS512groupOrder: 730750818665451621361119245571504901405976559617

g:[1026155954274139964772680638812782360987877053905146799488546796325522282950127835143485816862439054764322125772348776297750074484534151145760313869604549, 3152984641987606088228152123894158986782210823397743568528037659786831402386969445860046417657859164310800877675033826832886959374935824307782630720729659]

39

### User 1sk: 280422421148320423444728502160223251195926989322pk:[3158250831308395553258861743318879372691441060739374902659732051617713657498417490370187671750259858264936797956390260407285798173554451987314468876821617, 5302241150447538682293105512460529883754822132092559878345093799586309383065467771176163220629028722607568502075852365727125186477575253221907691576961666]Message: Message for test the Aggregate signatureσ :[2881739403911915578969704587150219569011248320153959619713991724913081816656661478185016611081998229764156713692798233711522568785742236214547167314982692, 665962975580422867318066169146208164924905704417722333730216856620417638849629677537281232360151824861335415040416491342604467578042940347903352317581503]

### User 2sk: 298060812719748466054047789653052918496997695072pk:[8393337766022375168623840769002076877547246460538871140246939842921714673898408919196622984139774834400518282260262088686175630505354797187298016096650353, 3868298084250612779292714802792256791435043580629684243656349764373548607521711167625739468812917606686489470697489309133168875568110226327344865595857244]Message: Aggregate signature sample 2σ :[916066525727051742971809618995548776887998804542978852293402991343111580999048049142435013655838886545256015963873959632932112556753275615257459863361606, 3746491454193403095208691947215922940905178627968098379369011413719526330479311512260384718957449803770271626638013292511873978371098418762551016078581378]

### User 3sk: 141998610832340742576508556115936864612165135911pk:[2534494758985408243194629269626779036547899595870813802331661685140583234422888931283254509582291767000396245573953428534749226355176398916845079986684663, 7089505849207808176695077240442771268185997733719664083111577529896422558436165667060212706579183703935043530441156516349559760914993546345192336046492591]Message: Another sample text for aggregate signatureσ :[2553394334991644630312536885113332212034559190458761971006867625853620296985312921144834220491449883270612645768833512846036513418785799910648885821384680, 739131603649431258438452395562845694714768320878494039648833547935431228376143896670960239404559464968030239708366966064291373921441915255980111064337267]

Aggregate Signature:[4171835623860494013175568569495140620527004280721006584137517491045235828929639883879964162223117379441126690450606940009776363880610835766066418633949700, 863263726749386720938949152327527399902279947805468010032435621388837338462746509251709146358869022733090708106633399350458183052074973783943166025693933]

e(σ, g) : 488873703569437295826405109582066967640053964279

k∏i=1

e(hi, Pki) : 488873703569437295826405109582066967640053964279

40

4.4 Ring SignaturesImplementation of the scheme explained in section 3.5 where from a group of three users the second member decides tocreate a signature that represents the whole group but does not reveal his own identity.

• A verifier is convinced that the signature was produced using one of the private keys of U but he is not able todetermine which one.

• Different members can use different public key signature schemes with different sizes and keys.

• Allows to specify a set of possible signers without revealing which member actually produced the signature.

groupType: SS512groupOrder: 730750818665451621361119245571504901405976559617

g:[1026155954274139964772680638812782360987877053905146799488546796325522282950127835143485816862439054764322125772348776297750074484534151145760313869604549, 3152984641987606088228152123894158986782210823397743568528037659786831402386969445860046417657859164310800877675033826832886959374935824307782630720729659]

Message: Ring signature message example

### User 1sk: 664398627942983981672797100642118310201033913017a1: 148381557194965493518797945797067403008413332507pk:[3445797573047236863115242779763144599233632550230981914276113678155507720716341316382958414107955685842167616650262913701439570771746277954815675476449538, 7582256709269052035526556762674360971455618740121067592477547360398983054392460989281473456050351537956873202598410366722573641156507322786645083456447823]σ :[1513662895986256868613827755506182441886525463952182912153116928853756090562704046819211049099775315345107287083342375114520320637499040799426662695025292, 1053717599380759568324080086987584683070138068215868683504319888301601031351495679610048798802040737398318705887707279752030028839229904046081004824567207]

### User 2sk: 572203165251177425296985010699267525543413580137a2: –pk:[7986423713080845026607897177213557401710862866933359881070834507475161293817114263083853174695142930476293341759201364487942666722533013798072517287205613, 4914042030128703689915913226331091799918429517879288157905249687544051994584124080536159760212221870961890266920647874773389435705458074826660662880041744]σ :[[519604919906841464004129112034722691762737318778497494735018360638654463791903526732662410188190976617420483497390327068922178219074663768437377477273830, 3819902096954515298709995987963134971589673208516616107256899547985552419468465965752902383864592057768530048340531672828487370015079963849961473723840348]

### User 3sk: 455568867744468830456942020236127671594211055244a3: 719014272414224559741159920315053744500469643884pk:[8760851258791394259619872230257538692669057015768797201142896534279351469217477406843956863031816357002831401340451676789230005521087085599934308188675274, 784420908571162129370978666033710232537007601378799464504574207101102012773088764615096558396561648143839217510597149414741357125405688

41

9482083100381553822]σ :[628323857309377793492372453102751121184575923350718010849834292831630443817517597107938605065813820512728197761575399235038673503591998731300678276384955, 6013205450098576482154876787879052323162902927620437253974053200901293851464243441821831670486209614486368023975925332431331121016889392287119306648362399]

Ring Signature:[519604919906841464004129112034722691762737318778497494735018360638654463791903526732662410188190976617420483497390327068922178219074663768437377477273830, 3819902096954515298709995987963134971589673208516616107256899547985552419468465965752902383864592057768530048340531672828487370015079963849961473723840348]

e(g, h) : 540552334113844496334001324558770891027277762276

n∏i=1

e(Pki , σi) : 540552334113844496334001324558770891027277762276

4.5 Verifiably Encrypted SignaturesImplementation of the scheme explained in section 3.6 where an user A wants to sign a message to user B but does notwant him to possess its signature of the message directly. The user A proceeds to encrypt his signature using the publickey of a trusted third party, the adjudicator, and sending the result to user B who can verify the validity but can not deduceany other information of the signature.

• User A creates a signature σ of the message M using his public key and a signature σ′ with the public key of theadjudicator. Then he combines both signatures σ and σ′ obtaining an aggregate signature ω, the verifiably encryptedsignature.

• User B validates the verifiably encrypted signature checking that ω is a valid aggregate signature of σ signature ofuser A and σ′ signature of adjudicator.

• The adjudicator, given a verifiably encrypted signature, can obtain the signature of user A by removing his σ′

signature from the aggregate signature ω.

groupType: SS512groupOrder: 730750818665451621361119245571504901405976559617

g:[2418203447943953849429718419201511176367612445991923457686612002318844016084170125644726352183179309533644716074802194995561271347397801064142406877714861, 3952702873387766041517606174793762936066277761252094153546133218230877244869577556033883514984720853514068201617664684377400066588970136204632421715115616]Message: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam dignissim sem at magna luctus tincidunt.Quisque pharetra ante at arcu mollis, sed dictum nibh cursus. Vivamus sit amet sem leo. Fusce mollis blandit varius.Aliquam ullamcorper magna sed ultrices dignissim. Vivamus nisi sapien, aliquam ut nulla a, rhoncus sodales sapien.Integer sodales tellus eget sem congue imperdiet.

### Signersk: 501605535419392316276934405869741252576353070315pk:[6160500225093520573358365778638265328928511293640639336941692406735328573891657224857615046342224852153774810147559774987541256162940200098066480040976501, 2229255905636493096974757158611425452

42

199272352962379202634300655264786321179697006600812829583076996863857161694687697646673752608259147667568751811546632]

### Adjudicatorsk: 517077572550850400533220801792896136674813003495pk:[3747689933029868427509541467086435516637775301656867974907577037987614858150176435159325581727468780214531885541791584811969586029789885679376154655418920, 162504856907303111315952751703565568100250859758381148475213758924709896411669928898514510750057444869312383232118214971099597504366753288017615465721648]

r: 208901437097547598872039205294204474319827342514

### Verifiably Encrypted Signatureω :[495471659707308113913347791516759730959868835271835378037510785178785036670775182643381448710365737310165311378838126215212092107176348058541006799761114, 3770125284624389422484847532374061142385169733163593501897520018883161091812744939979033444445878872535795738746066341126324888511624552529444653894606985]

µ :[3089749807885702041593798723316308802213372254025081045004783550341572447751788267364436962231559509290083937189268811665355018334355286816260994669704960, 332449480591104138233589866741079229225518818374614035299004737348932385958609094089232475448477314248237105708884111175139812684158436805026665202965351]

e(g, µ) : 696624920609391998773796622955589917483455750710

e(Pksigner , H(m)) : 696624920609391998773796622955589917483455750710

4.6 Group SignaturesImplementation of the scheme explained in section 3.7 where a user must convince that he belongs to a group but at thesame time his identity can not be revealed. Only the group manager can discover the identity of the signer if it is necessary.

• Only members of the group can sign messages.

• The receiver of the signature can verify that it is a valid signature of that group, but cannot discover which memberof the group made it.

• In case of dispute later on, the signature can be "openend" (with or without the help or the group members) to revealthe identity of the signer by the group manager.

groupType: SS512groupOrder: 730750818665451621361119245571504901405976559617

g1:[21131240631503483252236084605944582957224912832023801201049245449203712060185569935899296670088542818379823101567011195951077951083455692392559220401107, 1611266150917082643463721970466224305612224674940208100181865083242619698770800200774355428554268749527492961882563293668761424707863999262932580232265332]

43

g2:[21131240631503483252236084605944582957224912832023801201049245449203712060185569935899296670088542818379823101567011195951077951083455692392559220401107, 1611266150917082643463721970466224305612224674940208100181865083242619698770800200774355428554268749527492961882563293668761424707863999262932580232265332]

w:[1236295997915393317373529932294067187288831240758193928697506244217522021063283827261735339716785373237367997111221855833984020607061430876568425897099979, 4786684205278680807855060335311275092639882099385453616306356403771095034418171863680140828059388680185498070399076478669550712396630492075637772832222951]

γ: 158671505881240991841045418605897165761373265983ξ1: 239789442842886089049749972052321614667088178809ξ2: 239789442842886089049749972052321614667088178809

Message: Example text to test the implementation of the group signature scheme.

### User 1xi: 723186577549018022999152056564304837893766257031Ai:[7317977989782703872371862522530793354085050377835595988309257522460947328071020914255892246028683644994748969977007794635795026638887050748767082999079735, 7242737050366393980289833325458632104208332054808971603359267930852437164909749641133744686182224113419210926591619001592669413193361705499796338446514094]

### User 2xi: 108700560140573261920458307453803659420169019959Ai:[8108674867637164697472511687009610544473690497321749387645220392857578250718667632478730647733520181619712457832676611610066608131409613321033915601695298, 5140908799471693468349277098066130155062942166970486156439872559127662520794429770907115589803111454546128039082417325356190721467919749472535040920406278]

### User 3xi: 152687268650753520099672465075634116007218834587Ai:[5700688682936574958611145517058774257530297678203684877153387223653730024496519897306667860108895838073464195117296804486922126112050793416007510502985225, 2793378395884926174128425509267133998729304787881404125469038187182062908773227345455245714019466200483814646690150135889279265018367720607581201440142821]

### User 4xi: 574797365662541224148493198847053224001502997004Ai:[2611323138257894426515914786763771657291767263828537559111442401734183472661981580741063164178613281448610828543895896239056344382453428029642120696067641, 5893047238450090075154364743101882512671881769057885689131861067970055174724976569881334025333958374131364842878862071187051758842333644097205658641129333]

### User 5xi: 173787767292813286512741607075182384210869727179Ai:[6568984501459614971249278586862886659241158213383548176538042331067997987492165693655305468163453905255781823996785466657282188188956660518959973423935239, 7619905311863202381628231142918974776378497063551381821436417016633218533193343648912886157815982136590412825403151862778272493813324917127479524777617295]

44

### Group Signature

u:[5484734681378772968918144811850385800049214488718301805068477487289246447043585666522280415141627679630326810860251726643429173458033026938888898988378248, 8202514112563797458888053438893117358709714824438569815223441232373957479975342925139617301818976465753864923444812569465857347206118599035216211181846747]v:[5484734681378772968918144811850385800049214488718301805068477487289246447043585666522280415141627679630326810860251726643429173458033026938888898988378248, 8202514112563797458888053438893117358709714824438569815223441232373957479975342925139617301818976465753864923444812569465857347206118599035216211181846747]h:[2224047417313302275905586921378920633864966787417620458522878179734675761456606911020114241313239558116643711078245531284530156267393821258237988141863407, 4622354694779673905440463690850092101367327831639876822660179945231622395279787776754098254988212470952023404226737908839100008090921357910007015262813092]

α: 364608895484936323178684321328890256961975832385β: 23221911872091684918424760937684601486102589222

T1:[6278225952140385872686209621350469413883149753748239914968019506646890185767427166781091853518400854792367470717160817069735329685516862798799095891051512, 7792499645557976465966851809900304796883598820500199924763080563504365681950939173461235057539841086237616673823867601377105177785005476263396004308708551]T2:[8399144302257361574083872465699770135884946726335181192910286839517892469159021966003459532514051738058243285166925574821837847097899731236607457994054128, 6845123499433316014901663636591967409188420755026131337228622734197154929768555315636134031871897561260139531392603470357620883591944639346569960886551261]T3:[7212559997367660505909234907792889472848546816052070943684275639214423833360360948225603616862261321933201245689561283080425100158678616292029633777066155, 3950023082456256204938981459618377780616398916926381368672952700125526204936775353301306091934053098833790379780170445229943481457354787431208067974495441]

δ1: 24203110236795836009257447283057007965426294626δ2: 640940864196312002053017951486185858745856595773rα: 516936926795487566228395028764622948726526749400rβ: 86457738135915214093638642076473154105792429635rx: 641735569189025014558948496088087419123396120273rδ1 : 626025106317889136681674937439642995569706286050rδ2 : 188623072893817757140592573159409801822147159654

R1:[6872686459309500459191663542952129281855840125664527550055349867844826242963718493149400663872151225592337720551173498460020683647590625317839202037970549, 684787833830997079971943093562362290696318102263840018629597048545782028018868084181152009229253974104828231774041946220796869209407102067411526041816677]

45

R2:[7980274639525123701374029065623408547574253339427033370693222696025480346372890732970429957963485153308496228634591428397547466948977692461797532231824376, 8347075605722936029869174243450001425918737830363670634154268588396825921821041802467505854122924471371240245984807343502822433567705228248219472013875657]R3:[6639385840604536794898805193656451523131519785639202665000152320057277652610288168713560202544020996501303451388333348792616779314215213093385555356712402, 1200970421735079627763782914736837083308801104124834039161710318747790204435001272462573975017484355945751127142233836813551150598954532529557189936518779]R4:[7602170508477445706578144185471741439406536612867601929497923472945131100949895089895277531833516773488005698590417548063190256681440895941386528737465687, 7367611843776428255966061056226081998787028983343370647542941948572298481001686826786040403281534931787753906192694247180557357305987965307904022390617340]R5:[5057450630148366097184974334517936927578623009690007297027838268743878213609161230161513675768110201540389922334649902326251246128643229998658874023793274, 1206840024355485474633048823061252551838594340418815897544258953570032099287622540116247864562744499810403599522880527887685428565322394337681456226695072]

sα: 679398469867826723581775642950721116018145070842sβ: 596611184663279207484935721786145470015334276604sx: 202232100825737796546102580833815877304926567703sδ1 : 631898709139319944124465967483258594294035703955sδ2 : 169021331447300324200374239290792010153843532770

R1 :[6872686459309500459191663542952129281855840125664527550055349867844826242963718493149400663872151225592337720551173498460020683647590625317839202037970549, 684787833830997079971943093562362290696318102263840018629597048545782028018868084181152009229253974104828231774041946220796869209407102067411526041816677]R2 :[7980274639525123701374029065623408547574253339427033370693222696025480346372890732970429957963485153308496228634591428397547466948977692461797532231824376, 8347075605722936029869174243450001425918737830363670634154268588396825921821041802467505854122924471371240245984807343502822433567705228248219472013875657]R3 :[6639385840604536794898805193656451523131519785639202665000152320057277652610288168713560202544020996501303451388333348792616779314215213093385555356712402, 1200970421735079627763782914736837083308801104124834039161710318747790204435001272462573975017484355945751127142233836813551150598954532529557189936518779]R4 :[7602170508477445706578144185471741439406536612867601929497923472945131100949895089895277531833516773488005698590417548063190256681440895941386528737465687, 7367611843776428255966061056226081998787028983343370647542941948572298481001686826786040403281534931787753906192694247180557357305987965307904022390617340]R5 :[5057450630148366097184974334517936927578623009690007297027838268743878213609161230161513675768110201540389922334649902326251246128643229998658874023793274, 1206840024355485474633048823061252551838594340418815897544258953570032099287622540116247864562744499810403599522880527887685428565322394337681456226695072]

46

Finally the group signature that the algorithm outputs is:

σ ← (T1, T2, T3, c, sα, sβ , sx, sδ1 , sδ2)

### Signature CheckCheck that the challenge values {c = c′} as a result of the group signature:

c = 210802588810399102727518197440286545091744858981

c′ = 210802588810399102727518197440286545091744858981

### Signature OpeningWhen the group manager needs to recover the identity of the signer he computes Ai and compare with every Ai of everymember of the group:

Ai :[2611323138257894426515914786763771657291767263828537559111442401734183472661981580741063164178613281448610828543895896239056344382453428029642120696067641, 5893047238450090075154364743101882512671881769057885689131861067970055174724976569881334025333958374131364842878862071187051758842333644097205658641129333]

A4 :[2611323138257894426515914786763771657291767263828537559111442401734183472661981580741063164178613281448610828543895896239056344382453428029642120696067641, 5893047238450090075154364743101882512671881769057885689131861067970055174724976569881334025333958374131364842878862071187051758842333644097205658641129333]

- User 4 of the group is the original signer of the message.

### Verification CheckAfter the previously check we need to verify that it is a valid signature and it does not belong to a revoked user. We usethe {RL = Ai} just to validate the verification check scheme, in this example the signature belongs to the user 4 of theRL who has been revoked:

e(T3/A4, u) = 450949690520473807646100530037949440321122777785

e((T1 · T2)ξ1 , v) = 450949690520473807646100530037949440321122777785

47

48

Chapter 5Budget

This project took around 16 weekly hours during a period of 31 weeks which gives a total time spent of:

Spent time = 16h

week× 31 week = 496 h

If we take 20000C/year as the average salary for a junior engineering in Spain we got that the hourly rate is e:

Hourly rate = 2000012months×20laboraldays×8hoursperday = 10.41 e/h

Then we got that the budget for the project would be approximately:

Budget = 10.41 e/h ×496h = 5163.36 e

The remaining software used in the project is open source thus the budget would not be increased.

49

50

Chapter 6Conclusions and future development

The elliptic curve discrette logarithm is still a hard problem to solve, after a slow start since the first studies of NealKoblitz and Victor Miller in the mid-1980s mathematicians still have not found an algorithm to solve this problem. Themain advantage of elliptic curve based algorithms over factoring algorithms as RSA is the stronger security that they bringusing the same size of key. Indeed you can use smaller keys to get the same levels of security, a 228-bit elliptic curve keyhas the same level of security than a 2380-bit RSA key.

Nowadays with the huge rise of the mobile communicating devices a smaller key length means that the operations canalso be performed with smaller hardware that result in less heat, less power consumption and lower memory demands. Atpresent ECC has been widely implemented over different types of applications as for instance Bitcoins, SSH or TLS.16

• BitcoinsThe cryptocurrency Bitcoin is a distributed peer-to-peer digital currency which allows online payments to be sentdirectly from one party to another without going through a financial institution.Transferring ownership of bitcoinsfrom user A to user B is realized by attaching a digital signature (using user A’s private key) of the hash of theprevious transaction and information about the public key of user B at the end of a new transaction.

• SSH - Secure ShellElliptic curve cryptography can be used in three positions in the SSH protocol. In SSH-2, session keys are nego-tiated using a Diffie-Hellman key exchange. RFC 5656 specifies the ephemeral Elliptic Curve Diffie-Hellman keyexchange method used in SSH, following SEC1. Each server has a host key that allows the server to authenticateitself to the client.

• TLS - Transport Layer SecurityAll of the cipher suites specified in RFC 4492 use the elliptic curve Diffie-Hellman (ECDH) key exchange. TheECDH keys may either be long-term (in which case they are reused for different key exchanges) or ephemeral (inwhich case they are regenerated for each key exchange). TLS certificates also contain a public key that the serveruses to authenticate itself; with ECDH key exchanges, this public key may be either ECDSA or RSA.

Although cryptographic algorithms as RSA or Diffie-Hellman are still mostly used ECC is quickly getting more and moreattention since in a non-long term future it is probably that traditional schemes can be broken as well, and in this futurethe solution is Elliptic Curve Cryptography.

16 J. W. Bos, J. A. Halderman, N. Heninger et al. (Elliptic Curve Cryptography in Practice) 2013

51

52

Chapter 7Bibliography

[1] Whitfield Diffie and Martin E. Hellman. (New directions in cryptography, IEEE Transactionson Information Theory) 1976.

[2] Neal Koblitz. (Elliptic curve cryptosystems. Mathematics of Computation) 1987.

[3] Victor S. Miller. (Use of elliptic curves in cryptography) 1985.

[4] D. Hankerson, A. Menezes, S. Vanstone. (Guide to Elliptic Curve Cryptography) 2004

[5] Ben Adida. (Pairing-Based Cryptography) 2004

[6] Certicom. (An Elliptic Curve Cryptography (ECC) Primer) 2004

[7] Don Johnson, Alfred Menezes, Scott Vanstone. (The Elliptic Curve Digital Signature Algo-rithm) 2001

[8] D. McGrew, K. Igoe, M. Salter. (Fundamental Elliptic Curve Cryptography Algorithms) 2011

[9] Jose L. Muñoz. (Asymmetric Algorithms) 2012

[10] [11] Alexandra Boldyrva. (Efficient threshold signature, multisignature and blind signatureschemes based on the Gap-Diffie-Hellman-group signature scheme) 1991.

[12] [13] [14] Boneh, Gentry, Lynn and Shacham. (Aggregate and verifiably encrypted signaturesfrom bilinear maps) 2003

[15] David Chaum, Eugène van Heyst. (Group signatures) 1991

[16] J. W. Bos, J. A. Halderman, N. Heninger et al. (Elliptic Curve Cryptography in Practice)2013

53

• Multisignature related work[·] Itakura and Nakamura. (A public key cryptosystem suitable for digital multisignatures)1986

[·] Okamoto. (A digital multisignature shceme using bijective public-key cryptosystems) 1988

[·] Harn and Kiesler. (Group oriented (t,n) threshold digital signature shceme and digital mul-tisignature) 1989

[·] Ohta and Okamoto. (A digital multisignature scheme based on the Fiat-Shamir shcheme)1991

[·] Ohta and Okamoto. (Multisignature scheme secure against active insider attacks) 1999

[·] Boldyrva. (A efficient threshold signature, multisignature and blind signature schemes basedon the Gap-Diffie-Hellman-group signature scheme) 2002

• Blind Signature related work[·] David Chaum. (Blind signatures for untreacceable payments) 1982

[·] Bellare et al. (The One-More-RSA Invertion problems and the security of Chaum’s BlindSignature Scheme) 2001

• Aggregate Signature related work[·] Boldyrva. (A efficient threshold signature, multisignature and blind signature schemes basedon the Gap-Diffie-Hellman-group signature scheme) 2002

[·] Boneh, Gentry, Lynn and Shacham. (Aggregate and verifiably encrypted signatures frombilinear maps) 2003

• Ring Signature related work[·] Rivest, Shamir and Tauman. (How to leak a secret) 2001

[·] Moni Naor. (Deniable ring authentication) 2002

[·] E. Bresson, J. Stern and MSzydlo. (Threshold ring signatures and applications to ad-hocgroups) 2002

54

• Verifiably Encrypted Signature related work[·] Boneh, Gentry, Lynn and Shacham. (Aggregate and verifiably encrypted signatures frombilinear maps) 2003

[·] Steve Lu, Rafail Ostrovsky and Amit Sahai et al. (Sequential Aggregate Signatures, Mul-tisignatures, and Verifiably Encrypted SignaturesWithout Random Oracles) 2012

• Group Signature related work[·] David Chaum, Eugène van Heyst. (Group signatures) 1991

55

56

Chapter 8Glossary

AES Advanced Encryption Standard

DES Data Encryption Standard

DLP Discrette Logarithm Problem

ECC Elliptic Curve Cryptography

ECDH Elliptic Curve Diffie Hellman

ECDSA Elliptic Curve Digital Signature Algorithm

ECIES Elliptic Curve Integrated Encryption Standard

NSA National Security Agency

RSA Rivest, Shamir and Adleman

SSH Secure Shell

TLS Transport Layer Security

57