In this chapter, we proved that key privacy and data privacy in encryption schemes are related to a certain extent. In fact, under some conditions, we showed that one notion yields the other. This allows to use existing work on the data privacy of some schemes in order to derive their anonymity. Moreover, we defined the anonymity notion for key and data encapsulation mechanisms and pro- vided a study on the equivalence between this notion and the indistinguishability notion in these mechanisms.
Part II
Generic Constructions of Confirmer
Signatures
Chapter 3
Overview of Confirmer Signatures
Abstract. Designated Confirmer signatures were introduced to limit the verification
property inherent to digital signatures. In fact, the verification in these signatures is replaced by a confirmation/denial protocol between the designated confirmer and the signature recipient.
In this chapter, we give a short overview of designated confirmer signatures; we will start with the motivation behind such signatures, then provide the formal definition of these signatures as well as of their security properties, and finally, we will browse through the different realizations of these signatures from basic cryptographic prim- itives.
3.1
Motivation and definition
Digital signatures capture most of the properties met by signatures in the paper world, for instance the universal verification. However, in some applications, this property is not desired or at least needs to be controlled. The typical applications where we wish to restrain the holder of a signature from convincing other parties of the validity of the signature in question are:
Licensing software [Chaum & van Antwerpen, 1990] A software vendor is willing to embed
signatures in his products such that only the paying customers are entitled to check the au- thenticity of these products. Moreover, he does not wish these paying customers to convince other parties of the genuineness of his goods.
Contract signing [Goldwasser & Waisbard, 2004] An employer issues a job offer to a certain can-
didate. Naturally, the employer needs to compete with the other job offers in order to attract the good candidate. Therefore, he does not wish the offer to be revealed to his competitors. At the same time, the candidate needs more than a verbal or unsigned agreement in order to protect himself from the employer not keeping his promise. Finally, when the candidate
accepts the offer, the employer wishes to convert the job offer he has issued to a publicly verifiable one, instead of having to issue a new contact.
Undeniable signatures were introduced in [Chaum & van Antwerpen, 1990] for this purpose; they proved critical in situations where privacy or anonymity is a big concern, e.g. licensing soft- ware [Chaum & van Antwerpen, 1990], electronic cash [Chaum & Pedersen, 1993; Boyd & Foo, 1998; Pointcheval, 2001] and electronic voting and auctions. In these signatures, the verification can be only attained by means of a cooperation with the signer, called the confirmation/denial protocols. Unfortunately, this very virtue (verification with only the signer’s help) became their major shortcoming for many practical applications. The flaw was later repaired in [Chaum, 1995] by introducing the concept of designated confirmer signatures. In fact, this concept involves three entities, namely the signer who produces the signature, the designated confirmer who confirms or denies the alleged signature, and finally the recipient of the signature. Actually, in the litera- ture, there is a clear separation between designated confirmer signatures or confirmer signatures for brevity, and directed signatures [Lim & Lee, 1993] which share the same concept as confirmer signatures with the exception of allowing both the signer and the confirmer to confirm/deny signa- tures. Finally, a desirable property in confirmer signatures is the convertibility of the signatures to ordinary ones. Indeed, such a property turned out to play a central role in fair payment protocols [Boyd & Foo, 1998].
Syntax
A convertible designated confirmer signature (CDCS) scheme consists of the following procedures:
Key generation (keygen). This algorithm inputs a security parameter κ and generates prob- abilistically two key pairs (skS, pkS) and (skC, pkC) for the signer and for the confirmer
respectively.
ConfirmedSign (confirmedSign). On input skS, pkC, and a message m, the signer outputs a
confirmer signature signatureµ, then interacts with the signature recipient (via an interactive protocol) to convince him of the validity of the just generated signature.
Verification (verify). This is an algorithm, run by the signer on a just generated signature or by
the confirmer on any signature, to verify the validity of the alleged signature. The input to the algorithm is, in addition to the public keys pkS and pkC, the message, and the alleged signature, the random noncesrS used to produce the signature in case the algorithm is run
by the signer, or the private key skC in case the algorithm is run by the confirmer. The output
of this algorithm is either1 if the purported signature if valid on the message, or 0 otherwise.
Confirmation/denial protocols (confirm/deny). These are interactive protocols between the con-
firmer and a signature recipient (the verifier). Their common input consists of, in addition to pkS and pkC, the alleged signatureµ, and the message m in question. The confirmer uses
his private key skC to convince the verifier of the validity (invalidity) of the signatureµ on
m. At the end, the verifier either accepts or rejects the proof.
Selective conversion (convert). This is an algorithm run by the confirmer, on a messagem and its corresponding signatureµ, using skC, in addition to pkC and pkS. The result is either⊥
in caseµ is invalid w.r.t m, or a string which can be universally verified as a valid digital signature on the messagem w.r.t. pkS.
Selective verification (verifyConverted). This is an algorithm for verifying converted signatures.
It inputs the converted signature, the message, pkS, and pkC, and outputs either0 or 1.
Remark 3.1. In [Gentry et al., 2005; Wang et al., 2007], the authors give the possibility of ob-
taining directly digital signatures on a given message. We find this unnecessary since it is already enough that a CDCS scheme supports the convertibility feature. Moreover, in [Wikstr¨om, 2007], the author considers a further protocol used by the confirmer to prove the correctness of the con- version. Throughout this thesis, we will mention the constructions that extend to this augmented model.
Remark 3.2 (Security parameter). In the rest of this part, the security parameter of a construc-
tion consists of a tuple that comprises the security parameters used for the construction’s build- ing blocks. Thus, when we invoke the key generation or the setup algorithms of a construction’s building block on input a given security parameter, sayκ, we mean that we call the mentioned al-
gorithms on input the field inκ which corresponds to the security parameter of the building block
in question. The same remark applies for security; when we say that a construction’s component is secure for the security parameterκ, we mean that it is secure w.r.t. the field in κ corresponding
to the security parameter of this component.