can reveal the losing bids. (Suzuki et al., 2000) pro-
vides a Dutch-style sealed-bid auction protocol that
overcomes this issue. In this protocol, a distributed
decryption method is used in a multiple-auctioneer
setting. The protocol employs hash functions to cre-
ate hash chains for encryption and decryption.
3.4 Multicomponent Commitment
(Nojoumian and Stinson, 2010; Nojoumian, 2012)
proposes a couple of unconditionally secure Dutch-
style sealed-bid auction protocols. These construc-
tions do not require any auctioneer to participate in
the bidding and opening phases. A trusted initial-
izer first initiates the auction and then he leaves the
scheme. During the initialization phase, each bidder
B
1
,...,B
n
receives some information from the initial-
izer. In the opening phase, bidders determine the auc-
tion outcomes on their own. In this setting, η and
κ denote the minimum and maximum prices respec-
tively, i.e., θ = κ−η+1 denotes the number of prices.
Bidders are connected through point-to-point secure
channels. During the bidding phase, each bidder B
i
commits to his bid β
i
∈ [η, κ]. In the opening phase,
the winner reveals his bid and the losers prove that
their bids had been less than the wining price. All the
computations are performed in Z
q
. The prime q must
be large enough such that n
2
/q be very small.
4 EVALUATION AND ANALYSIS
The implementation of the selected Dutch-style
sealed-bid auction protocols was performed using Mi-
crosoft Visual Studio and also the Crypto++ library.
For the sake of simplicity, we used a common graph-
ical user interface for auctioneers and bidders. The
bulletin board in (Sakurai and Miyazaki, 1999) was
implemented as a table with bidders’ identifications
in rows and auction parameters in columns.
We selected all the cryptographic modules from
Crypto++ except for the construction of the poly-
nomials in protocols (Nojoumian and Stinson, 2010;
Nojoumian, 2012); for each polynomial g(x) = a
0
+
a
1
x
1
+··· + a
n−1
x
n−1
of degree n − 1, we simply gen-
erated n random numbers a
0
,a
1
,··· ,a
n−1
in the fi-
nite field Z
q
and then we submitted the array to the
related bidder. Moreover, the Diffie-Hellman library
in Crypto++ was used to generate large prime num-
bers for the protocols in (Sakurai and Miyazaki, 1999;
Sako, 2000). This library also provides generator α of
subgroup Z
q
(of order q) that is used in (Nojoumian
and Stinson, 2010; Nojoumian, 2012).
Note that initialization and verification times not
only consider the computational cost but also cap-
ture the communication overhead of the protocols. To
evaluate the auction protocols for various rounds, the
bidders were allowed to bid from the least element
in the price set to 100%, 75%, 50% and 25% of the
price set. For instance, in a price set of 100 elements,
a bidder could bid from P
1
to P
100
, P
75
, P
50
or P
25
re-
spectively. We will call this as price range hereafter.
We faced some challenges when we implemented
(Nojoumian and Stinson, 2010; Nojoumian, 2012).
For instance, the point-to-point channels among bid-
ders required n − 1 ports for every single bidder, i.e.,
n(n − 1) ports for n bidders on a single computer.
Furthermore, since the bidders conducted the auction
on their own, the opening phase had to be synchro-
nized. Therefore, a notify-and-receive technique was
implemented to resolve this issue (i.e., each bidder
announces his completion of one round and then he
waits until all the bidders accomplish this phase). The
same notify-and-receive method was adopted for the
opening phase of (Suzuki et al., 2000).
Note that the notify-and-receive technique led to
an increased verification time. However, even with
this extra delay, we could relatively estimate the veri-
fication time. This means that evaluating the test cases
in an auction system with ideal synchronized chan-
nels would certainly give more accurate verification
time for these protocols but the real implementation
of synchronized channels had been a big challenge
and still under debate among software engineers.
Generally speaking, the model of synchronous
channels might be (a) the sender sends a message and
all the receivers are guaranteed to get the message
within a period p, where the length of p is a con-
stant known to everyone from the start of the proto-
col, or even a stronger model in which (b) the sender
sends a message and all the receivers get the message
at exactly time t so that each receiver cannot rush and
change its behavior in the sending slot after seeing
the incoming messages. Neither is, of course, a very
realistic channel, which is why it is better to make
protocols that work in asynchronous network models.
Our evaluations were conducted on a computer
with an Intel i7-2600 CPU @ 3.4GHz processor and
16GB RAM. The protocols were tested with common
price set P consisting of 41 elements. They were also
evaluated with three combinations of bidders (i.e., 25,
50 and 75) and various modulus sizes (i.e., 128, 256,
512 and 1024). However, unconditionally secure pro-
tocols were only tested with 25 and 50 bidders since
they were computationally intensive. Finally, the pro-
tocol in (Suzuki et al., 2000) was verified with differ-
ent number of auctioneers (i.e., 5, 10, 15 and 20).
ImplementationandAnalysisofDutch-styleSealed-bidAuctions-ComputationalvsUnconditionalSecurity
109