DIGITAL CONTRACT SIGNATURE SCHEME BASED ON
MULTIPLE CRYPTOSYSTEM
Wang Lianhai, Manu Malek
Computer Science Department, Stevens Institute of Technology, Hoboken, NJ07030
Keywords: Digital contract signature, digital signature, multisignature, concurrent signature, public key
authentication.
Abstract: This paper presents a new type of signature, contract digital signature, based on Discrete Logarithm(DL)
and Elliptic Curve(EC) cryptosystems. Contract signature is similar to a real-life contract. No less than two
signers take part in a contract signature. After introducing the concept and definition of contract signature,
a scheme based on Discrete Logarithm (DL) and Elliptic Curve (EC) cryptosystems is presented. This
scheme allows signers, whose ordinary signature schemes use many different cryptographic systems, to
generate a single signature. The scheme requires neither a trusted arbitrator nor a high degree of interaction
between signers. We then prove that this scheme is secure under the discrete logarithm assumption.
1 INTRODUCTION
Digital signature(Rivest et al., 1978) is one of the
major means for authentication, and also one of the
major research subjects of modern cryptography.
Digital signature is the digital equivalent of hand
signature, whose major functionality is to achieve
user’s authentication of a digital message. It is
playing an increasingly important role in building
e-commerce and office automation. Digital
signature has also gained extensive interest due to
its being utilized in governmental agencies and
internal operations of enterprises.
A variety of digital signatures have been
proposed, such as multisignature(Okamoto,
1988)(Ohta and Okamoto, 1991), proxy
signature(Mambo et al., 1996), proxy
multisignature(Xiaoming et al., 2002)(Lian-hai and
Qiu-liang, 2004), and threshold digital
signature(Park and Kurosawa, 1996). However, to
date there has been no digital signature which
simulates a real-life contract. In real-life, two or
more signers, who may be from different
companies, participate in a contract. Such contracts
play a very important role in various economic
activities, so it is necessary to propose a kind of
signature that is similar to a real-life contract, with
the following characteristics:
(1) In its generation, this kind of signature uses
the signer’s public key and private key of ordinary
signature, making it more practical than other
signature types.
(2) Signers may use different parameters or
cryptosystems. This is different from the
multisignature (Okamoto, 1988)(Ohta and
Okamoto, 1991) proposed by Okamoto, which uses
the same parameters in same cryptosystem.
(3) Fairness in the signing process: In the
signing process, if one signer can’t obtain the
signature, the others also can’t obtain the signature
This kind of signature is the digital equivalent
of contracts and can be named “Contract
Signature”. It can be easily distinguished from
multisignature, which use parameters in the same
cryptosystem and seldom considers fairness in the
signing process. It can also be distinguished from
the “private contract signature” used in a contract
signing protocol or concurrent signature. This latter
type of signature resolves the problem of fair
exchange of signatures, but contract signature does
that with a single signature in a collaborative and
simultaneous manner.
Furthermore, contract signature does not have
the drawback of data expansion with the number of
signers, which is more similar to a real-life contract.
Moreover, in some applications, co-signers may be
associated with different roles/ positions and,
therefore, have different management liabilities and
authorization capabilities. Thus, contract signatures
267
Lianhai W. and Malek M. (2006).
DIGITAL CONTRACT SIGNATURE SCHEME BASED ON MULTIPLE CRYPTOSYSTEM.
In Proceedings of the International Conference on Security and Cryptography, pages 267-274
DOI: 10.5220/0002097802670274
Copyright
c
 SciTePress

generated by co-signers with different signing
orders often imply different meanings (In this case,
it is not necessary to consider fairness of signature
generation). Contract signature also suits well to
joint announcement between different governments,
ministries, and enterprises. So it can be used more
widely than signing protocols and concurrent
signatures.
1.1 Related Work
There are many real-life situation where multiple
signers need to sign the same message. A simple
solution is that every signer sign the message using
an ordinary signature scheme. But this has the
drawback that the data increases with the number of
signers. A multisignature (Okamoto, 1988)(Ohta
and Okamoto, 1991) scheme , whose goal is to
design a signature scheme without data expansion
with the number of signers, is a digital signature
scheme that allows multiple signers to generate a
single signature in a collaborative and simultaneous
manner. Moreover, in some applications, co-signers
in a signing group may be associated with different
roles/ positions and, therefore, have different
management liabilities and authorization
capabilities. Thus, multisignatures generated by the
same group of co-signers with different signing
orders often imply different meanings.
At the same time, as more business is
conducted over the Internet, the fair exchange
problem assumes an increasing importance. Early
work on solving this problem was based on the idea
of timed release or timed fair exchange of
signatures [8, 9, 10, 11]. Here, the two parties sign
their respective messages and exchange their
signatures “little-by-little” using a protocol.
Typically, such protocols are highly interactive with
many message flows. An alternative approach to
solving the problem of fair exchange of signatures
involves the use of a (semi-trusted) third party or
arbitrator
T who can be called upon to handle
disputes between signers. The idea is that
A
registers her public key with T in a one-time
registration, and thereafter may perform many fair
exchanges with other entities. To take part in a fair
exchange with
B ,
A
creates a partial signature
which she sends to
B . Entity B can be convinced
that the partial signature is valid (perhaps via a
protocol interaction with
A
) and that T can extract
a full, binding signature from the partial signature.
However, the partial signature on its own is not
binding for
A
. B then fulfils his commitment by
sending
A
his signature, and if valid, A releases
the full version of her signature to
B .
This protocol is fair since if
B
does not sign,
then
A
’s partial signature is worthless to B , and
if B does sign but A refuses to release her full
signature, then
B
can obtain it from
T
. The third
party is only required in case of dispute; for this
reason, protocols of this type are commonly
referred to as optimistic fair exchange protocols.
The main problem with such an approach is the
requirement for a dispute-resolving third party with
functions beyond those required of a normal
Certification Authority. In general, appropriate third
parties may not be available.
Concurrent signatures(Chen et al., 2004) and
concurrent signature protocols are also proposed to
solve this problem. In a concurrent signature
protocol, two parties
A and
B
can interact
without the help of a third party to sign (possibly
identical) messages
A
M
and
B
M
in such a way
that both
A and B become publicly committed
to their respective messages at the same moment in
time (i.e., concurrently). This moment is determined
by one of the parties through the release of an extra
piece of information
k which is called a keystone.
Before the keystone’s release, neither party is
publicly committed through their signatures, while
after this point, both are. In fact, from a third party’s
point of view, before the keystone is released, both
parties could have produced both signatures, so the
signatures are completely ambiguous. In a
concurrent signature scheme,
A first generates a
keystone
k and sends k to B . A and B
each generate ambiguous signatures
A
σ
and
B
σ
,
which are similar to ring signatures (Rivest et al.,
2001), in which an anonymous signer A wants to
have the option of later proving his authorship of a
ring signature. The solution was to choose bits
B
h
pseudo-randomly and later to reveal the seed used
to generate
B
h
. In a concurrent signature scheme,
before k is released, it can’t be assured that
A
σ
is
signed by A, and it can’t be assured that
B
σ
is
signed by
B . These assurances become possible
when
k is released. But these concurrent
signatures have the drawback that the data
expansion increases with the number of signers, and
also do not adapt to the cases of joint announcement
between different governments, ministries, and
enterprises. Moreover,
A may hide k and want
to publicize it when the contract signature is of
benefit to him. In this sense, the protocol is not fair.
SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY
268

1.2 Our Contributions
We introduce the notion of contract signature. A
contract signature scheme allows multiple signers,
who may be from different companies and may use
different parameters or cryptosystems, to generate a
single signature in a collaborative and simultaneous
manner. Signers They use the same public key and
private key as in their ordinary signature. This
makes the management of public key or digital ID
easier, and make contract signatures more practical
than multisignatures.
In the following sections, the paper presents a
contract signature scheme based on Discrete
Logarithm (DL) and Elliptic Curve (EC)
cryptosystems. Our contributions can be
summarized as follows:
(1) This scheme resolves the problem of
signers, whose ordinary signature scheme use
different cryptographic systems from each other,
generating a single signature. This is a major
question that should be resolved in each contract
signature. In the scheme described here, there are
two signers, one’s ordinary signature scheme is
based on Discrete Logarithm(DL), and the other’s
scheme is based on Elliptic Curve (EC)
cryptosystem. They can generate a secure contract
signature.
(2) In this signature generating process, if one
side can’t obtain the signature, the others can’t
obtain the signature either. We use a keystone,
similar to concurrent signatures, and set up a time
limit, to resolve the fairness property of generation,
without requiring a trusted third party.
(3) The scheme is secure: we prove that it is
secure under the discrete logarithm assumption and
ECCDH(Elliptic Curve Computational
Diffie-Hellman) assumption.
In Section 2 we provide the formal definition
of a contract signature and its properties. In Section
3 we present a contract signature scheme based on
DL and EC cryptosystems, and prove the
correctness of the scheme. In Section 4 we analyze
the scheme’s security.
2 DEFINITION OF CONTRACT
SIGNATURE
2.1 Description
Assume that
n
signers take part in the signing
process, and Signer
i
( 1,..., )in=
uses
(, , , , )
ii iii
PAK SV
to generate a digital signature, in
which
i
P
is a finite set of plaintexts,
i
A
is a finite
set of cipher texts of signature,
i
K
is a finite set of
keys,
ii
kK
∈
is the key to generate a signature,
i
ki
s
ig S
∈
is the signing algorithm and
i
ki
ver V
∈
is
the validating algorithm of signature.
Definition 1. A
Contract Signature scheme is a
digital signature scheme which is constituted by
(,, ,, )PAKSV
, and satisfies the following
proprieties:
(1)
P
is a finite set of messages
(2)
A
is a finite set of signatures
(3)
12
(, ,..., )
n
K
KK K
=
is a key Vector
(4) For each
( 1, 2,..., )
ii
kKi n
∈
= , there exists
a signing algorithm
12
( , ,..., )
n
kk k
s
ig S∈
and a
validating algorithm of signature
1, 2
( ,..., )
n
kk k
ver V
∈
.
For each message
x
, if
12
( , ,..., )
()
n
kk k
y
sig x=
, then
12
(, ,...,)
(, )
n
kk k
ver x y
would be true; otherwise it would
be false.
(5) For each
( 1, 2,..., )
ii
kKi n∈=
,
12
( , ,..., )
n
kk k
s
ig S
∈
and
1, 2
( ,..., )
n
kk k
ver V∈
can be calculated
in polynomial time.
1, 2
( ,..., )
n
kk k
ver V∈
should be
published; Everyone can use it to validate
signatures.
2.2 Basic Characteristics
Following are the characteristics of a contract
signature
Basic Security: In the process of signature
generation, any information broadcast by signer
i
is useless for others to compute the private key of
signer
i . That is, any broadcast information does
not affect the security of private key or ordinary
signature of signer
i
.
Unforgeability: If signer
i does not take part
in the process of signature generation, no one can
counterfeit his contract signature. In the generation
process of contract signature, the scheme should be
secure even though other
i-1 signers conspire to
forge the contract signature of signer
i
.
Undeniability:
Once having generated a
contract signature with proxy, none of the signers
DIGITAL CONTRACT SIGNATURE SCHEME BASED ON MULTIPLE CRYPTOSYSTEM
269

can deny it.
Fairness
: In the signing process, if one can’t
obtain the signature, the others can’t obtain the
signature either.
Key-dependence:
The signature key for a
contract signature generator depends on each
corresponding signer’s private key which was used
by the signer to generate an ordinary signature.
3 CONTRACT SIGNATURE
SCHEME BASED ON DL AND
EC CRYPTOSYSTEM
A contract signature generation may involve
different parameters and different cryptosystems.
As a result, a contract signature scheme is
comparatively more complicated than other types of
signature. Here, we study a simple form described
below. In later research, we will discuss other
complex forms.
In the case studier here, only two signers
participate in a digital contract generation, where
their digital signature schemes are based on
Discrete Logarithm (DL) or Elliptic Curve (EC)
cryptosystems.
3.1 Parameters
Let the two signers be
A
and B .
3.1.1 A ’s Parameters
A ’s ordinary signature parameters are the
following:
1
p is a large prime, an elliptic curve
1
E over
1
()GF q ,
11 1
(())GEGFq∈ is a finite point
of prime order in
1
()GF q . It can be presented as
follows:
1111111
(, ,,, ,),(, )DqFRabGndQ= , where
1
q is field size, where
11
qp= ;
An indication
F
R of the representation used for
the elements of
1
()GF q ;
Define the equation of the elliptic curve
1
E
over
1
()GF q :
23
11
yxaxb=+ + where
(
)
11 1
,ab GFq∈ ;
111
(, )
CC
Gxy= is a point of
1
(())EGFq and
11
()ord G n= ;
1
n is a large prime Integer,
160
1
2n > and
1
1
4nq> ;
1
d is A ’s private Key,
1
Q is
A
’s public key.
3.1.2 B ’s Parameters
B ’s ordinary signature parameters are as follows:
large prime
2
,pg
is generator of the unique cyclic
group of order
2
p
in
2
*
P
Z
;
h
is a hash function;
B ’s private key is
2
[1, 1]
B
xp
∈
−
and B’s public
key is
2
mod
B
x
B
yg p= .
3.1.3 Common Parameters
h is a hash functions;
Let the message for signature be
1
m
3.2 Generation
STEP1:
A
does the following:
- Selects a random
integer
11
[1, 1]kn
∈
−
;
- Computes
111 11 11 1
(, ), modRkG xy rx n
=
==
. If
1
0r
=
, then go to STEP1;
- Selects a random integer
32
[1, 1]kp∈−
, and a
random integer
2
[1, 1]kp
∈
−
;
- Computes
3
32
mod
k
rg p= and
2
(mod)
12
mod( 1)
k
hg p
fg p
=
−
;
- Sends
1
r
,
3
r
and
f
to B .
STEP2:
B
does the following :
- Selects random integers
22
[1, 1]kp
∈
−
,
41
[1, 1]kn
∈
−
;
- Computes
2
22
mod
k
rg p= . If
2
0r
=
,
then go to STEP2;
-
Computes
441 4444 1
(, ), modRkG xyrx n
=
==
;
- Selects a time variable
1
t
, where
1
t
is the time limit before which A must publicize
k
or respond to B , and B can announce that
the contract signature has been blanked out
within a day if he has not received
k
;
- Sends
1
t
,
2
r
and
4
r
to
A
;
STEP3:
A
and
B
compute
)1(
21
−
=
pnn
From
1
n
being a prime, we know
that
1
21
(1)modpn
−
− and
1
12
mod( 1)np
−
− exist. Let
SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY
270

3
2
1
32 1
1
41 2
23 2
11 4 4
(1)mod
mod( 1)
mod
r
r
lp n
ln p
rrr p
RRrRr
−
−
=−
=−
=
=+
12
mod( 1)frf p=−
11
mmt= &
, Here “ & ” denotes concatenation.
If
01mod)(
2
=−+ pmhf or
0mod)(
1
=+ nmhf , then go to STEP1;
Otherwise
A
computes
1111323341
(( ( )) ) ( 1) mod
s
fhmdrklp rkln n=+ − −−
,
and sends
1
s
to
B
;
Step4:
B uses the following equations to
validate
1
s
:
11 1 1 1
( ( )) (3.1)Rr Gs Q f h m+= +
3
1
32
1mod (3.2)
r
s
rg p=
If equations don’t hold, B terminates the signing
process. Otherwise,
B
computes
222414432
(( ( )) ) ( 1) mod
B
s
fhmx rklnrklp n=+−− −
and sends
2
s
to A
;
STEP5:
A
uses the following equation to
validate
2
s
:
22
()
22 2
mod (3.3)
rs
hm f
rg y p
+
=
44 1 2
(3.4)Rr Gs=−
A
Computes
12
,(,,,)
s
ss Rrsf=+ is the
contract signature obtained by
A
.
A
sends k to
B ;
STEP6: if
B receives k , then he uses the
following equation to validate
k :
2
(mod)
2
mod( 1)
k
hg p
frg p=−
If the equation holds, then
B
computes
12
,(,,,)
s
ss Rrsf=+
is the contract
signature obtained by
B .
If
B does not receive k before
1
t , or if the
above equation does not hold, then
B will announce
that
(,,, )Rrs f will be blanked out within a day,
and sends his ordinary signature to others signers.
The interactions between A and B are shown in
Figure 1
r
2
, r
4
, t
1
r
1
, r
3
, f
A B
s
1
s
2
k
Figure 1: Interactions between A and B.
3.3 Verification
When
m
and
(,,, )Rrs f
are received by us, we
first compute
1
t
from m, and check whether
B
has announced that this signature has been blanked
out before
1
t
+1 day. If yes, the verification fails.
Then we check whether
R
is a point on
1
E
. If not,
the verification fails.
We use the following equations to validate
whether
(,,, )Rrs f
is a contract signature of
m
:
11
(( ) ) (3.5)RGs Qhm f+= +
()
2
mod (3.6)
shmf
B
rg y p
+
=
2
(mod)
2
mod 1 (3.7)
k
hg p
frg p=−
If the above equations hold, then accept the
contract signature.
3.4 Correctness
In this subsection we prove the correctness of the
procedure.
3.4.1 Proof that Equations (3.1), (3.2),
(3.3) and (3.4) Work
Note that
12
(1)nnp
=
−
, therefore,
1
|nn
. So if
c
is an integer, then
11
mod mod modcnncn=
.
Thus
11
11
11132 3341 1
111 1
mod
mod mod
(( ( )) ) ( 1) mod mod
(()) mod
sn
snn
f
hm d rk l p rkln n n
fhmdrk n
=
=+ − −−
=+ −
12
12
11132 3341 2
11132 3341 2
33 2
mod 1
mod mod 1
(( ( )) ) ( 1) mod mod 1
(( ( )) ) ( 1) mod 1
mod 1
sp
snp
fhmdrklp rkln n p
fhmdrklp rkln p
rk p
−
=−
=
+− −− −
=+ − −− −
=− −
DIGITAL CONTRACT SIGNATURE SCHEME BASED ON MULTIPLE CRYPTOSYSTEM
271

22
22
22 41 443 2 2
22 2
mod( 1)
mod mod( 1)
(( ( )) ) ( 1) mod mod( 1)
( ( )) mod( 1)
B
B
sp
snp
fhmx rkln rklp n p
fhmx rk p
−
=−
=+ − − − −
=+ − −
21
21
22 41 443 2 1
44 1
mod
mo d mo d
(( ( )) ) ( 1)mod mod
mod
B
sn
snn
f
hm x rk ln rkl p n n
rk n
=
=+ − − −
=−
22 2 222
2222
222
(())
22 2 2
(())
22
(())
222
()
2
mod
mod
mod
mod
rs r fhmxrk
rfhmx rk
rfhmxr
hm f
B
r
g
r
g
p
r
gg
p
r
g
rp
yp
+−
+−
+−
+
=
=
=
=
So equation (3.3) is verified.
11 1 1 11 1 1 1 1
11 1 1 11 1
11 1 1 11
1
(( ( )) )
(())
(())
(())
Rr Gs Rr G f h m d rk
Rr G f h m d Grk
Rr G f h m d Rr
Qf hm
+=+ + −
=+ + −
=+ + −
=+
So equation (3.1) is verified.
3333
1
333
33
32 3 2
32
33 2
2
mod
mod
mod
1mod
rrrk
s
rrk
rr
rg rg p
rg p
rr p
p
−
−
−
=
=
=
=
So equation (3.2) is verified.
11 1 4 4
44
()Gs G rk
rR
−=−−
=
So equation (3.4) is verified.
□
3.4.2 Proof that Verification Equation
Works
To prove that verification works, we must prove
that equation (3.5) and (3.6) work.
First we prove that equation (3.5) works.
STEP1: Compute
1
mod
s
n
112 1
11132 3441
22 41 443 2 1
1
111442 2 1
111 44 1
mod mod mod
(( ( )) ) ( 1)
(( ( )) ) ( 1) mod mod
(( ( )) )( 1)( 1) mod
(()) mod
B
snss nn
fhmdrklp rkln
f
hm x rk ln krl p n n
fhmdrkkrp p n
fhmdrkkr n
−
=+
=+ − −− +
+−− −
=+ −− − −
=+ − −
1
11 4 4 1 1 1 1 4 4
11 4 4 1 1 11 1 1 4 4
11 44 1 1 11 44
1
(( ( )) )
(())
(())
(())
RGs
Rr Rr G f h m d rk rk
Rr Rr G f h m d Grk Grk
Rr Rr G f h m d Rr Rr
Qf hm
+
=+ + + −−
=+ + + − −
=+ + + −−
=+
So equation (3.5) is verified.
Next, we prove that equation
（
3.6
）
works.
212 2
11132 3341
22 41 443 2 2
1
22 33 1 1 2
22 33 2
mod( 1) mod mod( 1)
(( ( )) ) ( 1)
(( ( )) ) ( 1) mod mod( 1)
(( ( )) ) mod( 1)
(()) mod(1)
B
B
B
sp ssnp
fhmdrklp rkln
fhmx rklnkrlp n p
fhmx rk rknn p
fhmx rk rk p
−
−=+ −
=+ − −− +
+
−− − −
=+ −− −
=+ − − −
32233
2
333
222
33
22
(())
23 2
(())
23 2
(())
23 2 3 2
()
2
mod
mod
mod
mod
B
B
B
rfhmxrkrk
r
s
rrk
rfhmxrk
rr
rfhmxr
B
fhm
B
rg r r g p
rrg g g p
rry r r p
yp
+−−
−
+−
−
+−
+
=
=
=
=
So equation (3.6) works.
□
4 SECURITY ANALYSIS
We will discuss the security of our scheme under
Discrete Logarithm Assumption and ECCDH
Assumption
.
4.1 Security Characteristics of the
Scheme
We will prove that this scheme is secure under the
Discrete Logarithm Assumption and ECCDH
Assumption.
4.1.1 Basic Security
We have proved that in this scheme, signer
A
and
signer
B
cannot compute
1
d
or
B
x
from
1
s
SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY
272

or
2
s
under the computational discrete logarithm
assumption and ECCDH assumption. The proof is
rather long, and omitted due to space limitation.
4.1.2 Nonfakability
We have proved that the scheme is secure under
outsider impersonation attacks, insider
impersonation attacks, and Man-in-the-middle
attack. The proof is rather long, and omitted due
to space limitation..
4.1.3 Fairness
In a contract signature, fairness is very important. In
our signature scheme, if one can’t obtain the
signature, the others also can’t obtain the signature.
To show this, note that in Step4,
B
obtains
the contract signature
(,,, )Rrs f
, but if B does not
send
2
s
to
A
, then
A
can’t obtain the contract
signature
(,,, )Rrs f
. But we should note if
A
has not received
2
s
, he will not send
k
to
B
; So
the contract signature
(,,, )Rrs f
obtained by
B
does not satisfy the equation (3.7). Before
B
can
compute
k
, he should first resolve the discrete
logarithm problem to compute
2
(mod)
k
hg p
, and
them compute
2
mod
k
g
p
from
2
(mod)
k
hg p
,
and then compute
k
from
2
mod
k
g
p
. From our
discrete logarithm assumption, it can’t be computed
within polynomial time. If
k
cannot be obtained,
the contract signature
(,,, )Rrs f
obtained by
B
is not a valid signature. So if
A
has not obtained
the contract signature,
B
also has not obtained the
valid contract signature.
In Step5,
A
has obtained the valid contract
signature, but if she wants to that his signature is
valid, he should publicize
k , then
B
also obtains
k , and obtains the valid contract signature. So, the
process is fair. Moreover,
A
may hide
k and
want to publicize it when the contract signature is
of benefit to him. But if
B can not receive k
before time
1
t
, then B will publicize his ordinary
signature which announce that
(,,, )Rrs f has
been blanked out within a day and sends his
ordinary signature to others signers. If
A
didn’t
send
k to B before time
1
t , then (,,, )Rrs f
will be blanked out.
If a few days later
B
regrets having signed
the contract, he want to public his ordinary
signature which announces that
(,,, )Rrs f has
been blanked out. But because
A
has publicized
k , or one day has passed, his ordinary signature
which announce that
(,,, )Rrs f have been
blanked out is valid. So our scheme is fair.
4.1.4 Nonrepudiation
From 4.1.1 and 4.1.2, we know that only
A
can
compute
1
s
and only
B
can compute
2
s
, No one
can impersonate
A
and
B
to sign a contract
signature. So
A
and
B
can’t deny that they have
signed a contract signature.
5 CONCLUSIONS AND FUTURE
WORK
This paper has presented a new type of signature:
contract digital signature scheme based DL and EC
Cryptosystems. The scheme resolved the problem
of how signers whose ordinary signature schemes
use different cryptographic systems, generate a
single signature. The scheme requires neither a
trusted arbitrator nor a high degree of interaction
between signers. We believe that contract signatures
can be used more widely than signing protocols and
concurrent signatures.
The scheme presented here is only a simple
form of contract signature. There are many more
related problems for further study, such as the
multi-party contract signature scheme, contract
signature scheme based on RSA and DL
Cryptosystems, and contract signature scheme
based on RSA, DL, and EC Cryptosystems.
REFERENCES
R. Rivest, A. Shamir and L. Adleman. A method for
obtaining digital signatures and public-key
cryptosystems. Communications for the ACM,
1978,21:120-126.
T. Okamoto. Digital multisignature scheme using
bijective public-key cryptosystems. ACM
Transaction on Computer systems, 1988,6(4):
432-441.
K. Ohta and T. Okamoto. A digital multisignature
scheme base on the Fiat-Shamir scheme. In
Advances in Cryptology ASIACRYPT '91, LNCS
Vol. 739, H. Imai, R. Rivest and T. Matsumoto ed.,
Springer-Verlag, 1991. 139-148.
DIGITAL CONTRACT SIGNATURE SCHEME BASED ON MULTIPLE CRYPTOSYSTEM
273

M. Mambo, K. Usuda, and E. Okamoto. Proxy signatures:
Delegation of the power to sign messages. In IEICE
Trans. Fundamentals, 1996, Vol. E79-A, No. 9, Sep.,
pages 1338--1353.
Wang Xiaoming, Fu Fangwei, Security analysis of a sort
of proxy multisignature scheme [J] Journal of China
Institute of Communications 36(4), 2002: Page
98-102
Wang Lian-hai ,Xu Qiu-liang. Proxy signature Based on
the elliptic curve cryptosystem.[J] Application
Research Of Computers, 4, 2004, Page 122-126.
C.Park, and K. Kurosawa. New ElGamal Type
Threshold Digital signature Scheme. IEICE Trans.
Fundamentals, 1996, E79-A(1):86-93.
D. Boneh, and M. Naor, Timed commitments (extended
abstract). In Advances in Cryptology - CRYPTO 2000,
LNCS vol. 1880, pp. 236-254. Springer-Verlag, 2000.
S. Even, O. Goldreich, and A. Lempel, A randomized
protocol for signing contracts. In Commun. ACM, vol.
28(6), pp. 637-647, June 1985.
O. Goldreich, A simple protocol for signing contracts. In
Advances in Cryptology - CRYPTO 1983, pp.
133-136, Springer-Verlag, 1983.
J. Garay, and C. Pomerance, Timed fair exchange of
standard signatures, In Proc. Financial Cryptography
2003, LNCS vol. 2742, pp. 190-207, Springer-Verlag,
2003.
Liqun Chen, Caroline Kudla, and Kenneth G. Paterson.
Concurrent Signatures. In: EUROCRYPT 2004,
LNCS 3027, pp. 287-305. Springer-Verlag, 2004.
R. Rivest, A. Shamir and Y. Tauman, How to leak a secret.
In Advances in Cryptology - ASIACRYPT 2001,
LNCS 2248, pp. 552-565, Springer-Verlag, 2001
A. Menbezes, Elliptic Curve Public Key Cryptosystem,
Kluwer Academic Publishing, Boston, 1993.
SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY
274