Reprint

ISSN 2250-0367

INTERNATIONAL JOURNAL OF
MANAGEMENT STUDIES,
STATISTICS AND
APPLIED ECONOMICS

T PUBLICA
EN

N l
TIO

ASC

(IJMSAE)

ASCENT
PU

NE, INDI

www.ascent-journals.com

InternationalJour. of Manage.Studies.,Statistics & App.Economics

(IJMSAE), ISSN 2250-0367, Vol.2, No. I (June 2012), pp. 187-203

DIGITAL SIGNATURES: TECHNOLOGY,

MANAGEMENT AND APPLICATIONS

MOHAMMAD NABIL ALMUNAWAR

Abstract
The explosive growth of e-commerce transactions over the Internet; the widespread of e-business and
e-government have increased the need to support dutiful transaction. Digital signatures are codes
generated by an asymmetric or public-key cryptosystem. They are antithetical to hand-written
signatures but still preserve their functions. Many nations have passed legislation on digital signatures,
which give them equal legal standing with hand-written signatures. However, an infrastructure is
needed to manage applications of digital signatures in many-to-many relationships environment such
as the Internet. This paper discusses concepts, technologies and management of digital signatures. In
addition, some applications of digital signatures are also highlighted.

-----------------------------------Keywords : digital signature; public-key; PKI; digital certificate

http: //www.ascent-journals.com

188

MOHAMMAD NABIL ALMUNAWAR

1. INTRODUCTION
Technically a signature is an object that represents a person in approving, accepting or
owning another object especially a document or message. Thus if a person signs a document,
it implies that he/she authenticate the document.
A signature carries legal consequences. For instance, when two parties sign a contract, they
are bound legally with all terms in the contract. Consequently a signature must be able to
preserve three important requirements: unique, verifiable and undeniable. However, it is
rather difficult to achieve these requirements by a hand-written signature alone. Therefore
for an important document, other signatures (such as signatures of witnesses or solicitors) are
needed to help in confirming the authenticity of the document and the signatures.
In the conventional business or commerce environment, most transactions are authenticated
by hand-written signatures such as order and shipment documents as well as payments.
However, hand-written signatures cannot be applied in the cyberspace environment, where
the party that transacts are most likely to have never met before.
In the cyberspace environment, there are at least three essential features which needed to be
taken care of, namely security (message integrity), attribution and non-repudiation [10; 15].
Security is the guarantee of validity of document transferred; attribution means that the
source of document can be identified with certainty and non-repudiation means that the
sender of the document cannot deny sending the document. Digital signatures must preserve
these three essential features.
Digital signatures are so distinct from hand-written signatures but their functions are
preserved. Hence, digital signatures can be used to substitute hand-written signatures. In fact,
with the recent development of e-business, e-commerce and e-government, many nations in
this world have passed legislation on digital signatures, which give them equal legal standing
with the traditional hand-written signatures.
Note that the applications of digital signatures extend beyond the traditional signature
functions. For example, the technology used to develop digital money or electronic is based
on digital signatures.

DIGITAL SIGNATURES: TECHNOLOGY, MANAGEMENT AND APPLICATIONS

189

Digital signatures are basically codes generated by a cryptosystem. A well-known

cryptosystem used to generate digital signatures is the public-key cryptosystem. In the
public-key cryptosystem, a user has two different but related keys called private-key and
public-key. A private-key must be kept secret all the time while the public-key is freely
disclosed.
To digitally sign a document a person encrypts the document using his/her private-key, thus
the document is authenticated. The one who digitally signed the document cannot deny
(non-repudiation) that he/she has signed the document if the document can only be opened
by the related public-key. The concept and the detail of how digital signatures work will be
discussed in this paper. The paper also highlights some interesting applications of digital
signatures.
This paper is organized as follows: section two discusses the concept and technology of
digital signatures, followed by a discussion on digital signature management in section three.
Section four explores the current applications of digital signatures and finally the conclusion
is presented in section five.

2. CONCEPT AND TECHNOLOGY OF DIGITAL SIGNATURES

As mentioned above, digital signatures are basically codes generated by a cryptosystem. The
notion digital signature was introduced when Diffie and Hellman [6] published their paper
on the public-key cryptosystem. Unlike the previous cryptosystem that use only one key to
encrypt a message, the public-key cryptosystem use two related keys namely a private-key
and a public-key. If a message is encrypted using a private-key then the encrypted message
can only be decrypted using the corresponding public-key or vice versa.
There are several advantages of the public-key cryptosystem over the traditional single key
cryptosystem; one of them is the idea of digital signatures. When a party encrypts a message
using a private-key the only way to decrypt the message is using the corresponding publickey. In other words, if a message can be decrypted using a public-key then the message must
have been sent by or belonged to the one who encrypted it using the corresponding private-

190

MOHAMMAD NABIL ALMUNAWAR

key. The idea of digital signatures comes from this feature since it preserves an exclusive
ownership.
While the idea of the public-key cryptosystem and digital signature were introduced by
Diffie and Hellman, the current popular public-key cryptosystem and digital signatures were
developed by Rivest, Shamir, and Adleman [20] known as RSA public-key and RSA digital
signatures. The RSA cryptosystem is based on the principle that if two large prime numbers
is multiplied then the resulting number is hard to factor back to its original numbers. The
RSA digital signatures are based on the following equations:
s = md mod n

(1)

m' = se mod n

(2)

Equation (1) is the signature generation equation where s is the signature generated from
the message m, the private exponent d and the modulus n, while mod is the modulo
(remainder) operator. Equation (2) is the signature verification equation where m' the
original message decrypted from the signature s using the public exponent e and the modulus
n. Note that the pairs (d,n) and (e,n) are the private-key and the public-key respectively.
Next, the RSA digital signature algorithm or the RSA cryptosystem in general is based on
the principle that if two large prime numbers are multiplied the resulting number is hard to
factor back to its original numbers. In the above equations, the modulus n is a product of two
prime numbers. The larger the modulus n, the harder it is to factor it back. Note that both the
private exponent d and the public exponent e are derived from the two prime numbers that
form the modulus. According to an estimate made by Silverman [24] it takes 2 months on
300 networked PCs of 500-MIPS having at least 64 Mbytes of memory to factor 512-bit
key. However, it will take 7 million times longer with 2650 times the memory to factor
1024-bit key.
Theoretically, to sign a message, it is processed using the equation (1). However, the
message can be any length. Signing a long message using equation (1) or verifying it using
equation (2) is time consuming, thus a way to simplify the signature generation and
verification must be found. The hash function is the answer. The hash function is a one-way

DIGITAL SIGNATURES: TECHNOLOGY, MANAGEMENT AND APPLICATIONS

191

function that digests any message, producing a small fixed-length and unique representative
of the message.
The basic signature generation and verification operation can be seen in Figure 1 and Figure
2 respectively. Note that the signature generated will be attached to the original document to
form a digitally signed document.
How can a digital signature be verified? Suppose Hasan sent a document with his digital
signature to Husain. To verify that the document was indeed signed by Hasan, upon
receiving the document, Husain applies the same hash function used by Hasan to the
document to yield a hash value. Next, he decrypted the signature using Hasans public-key to
get back the digested message, which is the source of Hasans signature. If the hash value is
the same as the digested message then Hasans signature is valid, otherwise it is invalid.
Figure 2 shows the above verification operation.

Message

hash value
Hash

h(m)

RSA
Signing

h(m)d mod n

Signature
s

Figure 1: Signature generation operation

There are several important features of the above generation and verification operations.
First, a persons digital signature theoretically cannot be forged since the person can only
create ones signature using ones private-key. This implies signer authentication. Second, a
person cannot deny if one signed a document since ones signature can only be verified using
ones public-key, this is known as non-repudiation property, which assures the origin of the
document. Third, the hash operation preserves the originality of the document (document
integrity). The document cannot be changed since even a very simple change will generate a
different hash value and hence generate an invalid verification. Thus, the digital signatures
have few important features, which are very difficult to be matched by hand-written
signatures: signer and document authentication simultaneously.

192

MOHAMMAD NABIL ALMUNAWAR

se mod n
Message

RSA
verification

Hash

Signature
s

h(m)

Digested
Message

Hash
value

h(m)

h(m) = h(m)
?

Yes

Valid

No

Invalid

Figure 2: Signature verification operation

To make a strong document authentication, the hash function must be cryptographically

secure, which basically must be strictly one-way function (given a hash value, it is hard to
generate the original message) as well as a unique hash value generator (two different
massages cannot have the same hash value). There are many hash functions available,
however only few are considered secure enough to be widely used such as MD5 [21] and
SHA-1 (FIPS, 1995) which digests input into 128-bit and 160-bit respectively [2].
There are three main RSA signature scheme, namely PKCS #1, ANSI X9.31 and PSS [13]
PKCS #1 was developed by RSA laboratories Public-Key Cryptography Standard.
According to Kalaski Jr [13], PKCS #1 is widely used, for example most of digital
certificates in the Secure Socket Layer (SSL) protocol is signed using PKCS #1 v1.5 (See
http://www.rsasecurity.com/rsalabs/pkcs/ for detail). ANSI X9.31 was developed in the late
1990s by ANSI X9F1, the body that produces standards for the U.S financial industries.
According to Kalaski Jr [13], ANSI X9.31 was not widely deployed although it is supported

DIGITAL SIGNATURES: TECHNOLOGY, MANAGEMENT AND APPLICATIONS

193

by standard bodies such as FIPS 186-2, IEEE Std 1363-2000 and ISO/IEC 14888-3. PSS
(Probabilistic Signature Scheme) was introduced by Bellare and Rogerway [1]. Unlike
PKCS #1 and ANSI X9.31, PSS offers proof of security.
Of course there are other standards such as Digital Signature Standard (DSS) published by
The US Federal Information Processing Standards Publications [8]. However, in general,
digital signature generation and verification use the public-key cryptosystem combine with a
secure hash function.

3. DIGITAL SIGNATURES MANAGEMENT

Recall that digital signature technology uses a public-key to verify a signature. Everything is
fine if the receiver of a message trusts the senders public-key. However, in the Internet
environment where parties that involve in transactions never meet, how do you make sure
that a particular public-key really belongs to its real owner? This is not a simple problem.
The problem cannot be solved between two parties that are establishing transactions. Thus, a
third trusted party is needed to help confirming the transactions.
Suppose Hasan and Husain, unknown to one another, would like to establish a transaction
through the Internet. To establish a secure connection and to apply digital signatures, they
need to exchange their public-keys. Before Hasan and Husain use the public-keys, they will
consult with a trusted party (known as certificate authority or CA) to advise them whether
the public-keys are the authentic ones. If the trusted party acknowledges the authenticity of
their public-keys then Hasan and Husain can proceed with the business deal. So, in general a
public-key must be certified by a CA that guarantees the key belongs to the genuine owner.
A public-key certification issued by a CA is commonly called digital certificate, containing
at least information about the owner, the public-key and the expiry date, and digitally signed
by a CA. Note that every CA has a digital certificate which is issued by a higher level
authority and so on up to the root issuer forming a hierarchy called Public-Key Infrastructure
(PKI). PKI is basically a hierarchy of organizations that issue and validate digital certificates
which in turn are used to legalise digital signatures. A CA can be a bank, a large enterprise, a
government agency or a third-party consortium [5].

194

MOHAMMAD NABIL ALMUNAWAR

3.1 Digital Certificates

A digital certificate is an object containing a public-key: the owner's and related information
to guarantee the authenticity and the validity of the public-key and its owner. One of the
most popular standards specifying digital certificates is X.509 [12] published by
International Telecommunication Union (ITU).
The X.509 digital certificate (version 3) is basically a record that contains the following
fields: version, serial number, signature, issuer, validity, subject, subject public-key info,
issuer unique ID, subject unique ID, extensions, signature algorithm and signature value.
Let us discuss these fields in a bit detail. Note that if you are interested in seeing the
technical details of the certificate structure please read the X.509 certificate profile
(http://www.ietf.org/rfc/rfc2459.txt).
The value of field version (such as 3 for version 3) describes the version used to encode the
certificate and the serial number is a unique integer assigned by a CA to each certificate for
its identification. The signature and issuer fields contain the identifier of the algorithm used
by the CA to sign the certificate and the identity (which is a unique name) of the CA who
issued the certificate. The validity field describes the validity period warranted by the CA. It
contains two time points (intervals), the beginning time and the expiration time respectively.
The time must be expressed in Greenwich Mean Time and must be specific, as to include the
exact time, down to seconds.
The subject and subject public-keys are strongly related. Subject identifies the owner of the
public-key describes in the public-key info field and this contains the encoding of the publickey and the identification of the algorithm with which the key is used. Note that the subject
can be a CA since a CA has a digital certificate issued by a higher authority.
The fields issuer unique ID and subject unique ID exist in both versions 2 and 3 however,
the field extensions only exists in version 3. Both issuer and subject IDs are used to handle
the possibility of reusing issuer and subject's names. However, names cannot be reused by
different entities. For example, the same subject can reuse a name of the old certificate to
generate a new certificate with the same subject name but with a different subject ID. The
extension provides methods for associating additional attributes with user or public-keys and

DIGITAL SIGNATURES: TECHNOLOGY, MANAGEMENT AND APPLICATIONS

195

for managing the certification hierarchy. The value of field extensions is a sequence of one
or more certificate extensions.
Finally, signature algorithm contains the identifier and optional parameters of the
cryptographic algorithm used by a CA to sign the certificate while the signature value
contains the digital signature of the CA.
There are several types of digital certificate offered by CAs depending on the level of trust
needed. For example, high level of trust of digital certificates are needed to authorize large
financial transactions between banks, while such high degree trust is not needed for user
authentication in a local network or to protect email documents [15].
3.2 Public-key Infrastructure
As mentioned before, Public-key Infrastructure (PKI) is a hierarchy of organizations that
issues and validates public-keys. PKI is needed to facilitate the use of digital signatures in a
large and open environment such as the Internet [15].
X.509, also called PKIX for short, is a standard public-key infrastructure for the Internet.
There are several entities involved in the infrastructure; the key body is a CA. In general, a
CA issues a digital certificate requested by a subject called an end entity. Issued certificates
are stored in Issued Certificate List (ICL). A CA also revokes invalid certificates, such as
expired certificates or cancelled certificates and records them in Certificate Revocation List
(CRL). Registration Authority (RA) is an optional entity to which a CA delegates certain
management functions. Figure 3 shows the simplified PKIX architectural model published in
the X.509 standard [15].
An end user of a public-key who needs to validate a digital signature needs to ensure that the
public-key is indeed related to the private-key used to generate the digital signature.
Validating a digital certificate must precede every use of the public-key that it certifies. The
first step in validating the public-key is to check that the digital certificate is not expired. The
second step is to ensure that the certificate is not a member of CRL issued by the CA.
Therefore checking the CRL repository is definitely necessary. This can be conducted
immediately if the user of the public-key is confident with the CA that issued the certificates.
Otherwise a chain of validations through a certification path is required.

196

MOHAMMAD NABIL ALMUNAWAR

operational /management
transaction

End Entity (EE)

management
transaction

ICL/CRL
Repository

publish
certificate

Registration
Authority (RA)

publish certificate/CRL

Certificate
Authority
management
transaction

Certificate
Authority

Figure 3: PKIX architectural model (source: [15])

An example of a certification path hierarchy is the one defined in the Internet Privacy
Enhanced Mail (PEM) RFC 1422. The highest or the root in the hierarchy is the Internet
Policy Registration Authority (IPRA) which operates under the auspices of the Internet
Society. All certification paths start with the IPRA. The next level or level 2 is Policy
Certification Authorities (PCAs). Each PCA is certified by the IPRA and each PCA has its
own policy concerning services given to satisfy different user needs. Level 3 or lower levels
are Certification Authorities (CAs).
Certificate extension provided in X.509 v3 offers more flexibility than the RFC 1422. It
allows certification paths starting with the public-key of a CA in a user's own domain or with
public-key on the top of a hierarchy. It can replace PCAs with policy extensions and policy
mappings, which permits greater degree of automation.

DIGITAL SIGNATURES: TECHNOLOGY, MANAGEMENT AND APPLICATIONS

197

X.500-based PKI is rather complex since it needs global certificate hierarchies. There are
some other proposals for simpler and more flexible PKI such as SDSI [19] SPKI [25] and
their integration, SPKI/SDSI.
Compared to X.509 certificates, SPKI certificates are much simpler, containing only five
elements: issuer, subject, delegation, authorization and validity dates. Issuer and subject are
mandatory elements and other elements are optional. Issuer is the public-key of the one who
issues and signs the certificate. Subject holds the public-key or the name of the certificate's
owner. Delegation indicates if the issuers give the subject any right to re-delegate the rights,
which the issuer gives to the subject. Authorization means access rights. When an issuer
signs a certificate for a subject, it usually defines what rights the subject will have. Finally,
validity dates are used to define the legitimacy period of a certificate by an issuer.
3.4 Managing Private-keys
Much of the discussions of management of digital signatures emphasize on public-keys such
as the lengthy discussion on digital certificates and PKI. So far the big assumption that must
be held for applying digital signatures successfully is that a private-key must be a private
belonging which should never be shared, disclosed or stolen. Let us observe briefly what will
happen if a private-key is breached.
Suppose P is unaware that his private-key has been disclosed. A person Q masquerading as
P sends a digitally signed order message to R. R then checks the signature with a CA
whether the message is really signed by P. Since so far P has not revoked his private-key, the
CA acknowledges that the signature is indeed made with P's private-key. R then sends
merchandise to the address specified by Q and subsequently bills P. Definitely P will
complain to R since he has never ordered such merchandise, however R has a proof that P
digitally signed the order and P cannot repudiate.
If the digital signature law follows the technical definition of the non-repudiation of digital
signatures then the signer must prove that his/her signature was not signed by him/her. Note
that in this case the disclosure of a private-key can be considered as negligence [16].
However, it is highly possible the private-key is stolen especially if it is stored in the hard
disk of a computer. Kaner [14] provides several interesting examples how a private-key can

198

MOHAMMAD NABIL ALMUNAWAR

be stolen by using old fashioned hacking, Trojan horses, current software technologies such
as electronic registration and bug reporting or by exploiting security flaw on browsers.
Therefore, protecting private-keys is crucial.
The following highlights methods for protecting a private-key from less secure one to the
secure one. Nobody should store a private-key with plaintext in a desktop because the key
can be stolen easily through several ways as mentioned above. Storing a private-key in an
encrypted form in a desktop is much better. PKCS#8 offers a standard for encrypting a
private-key using a master key derived from a user's password. Several other methods such
as embodied in PKCS#11 and PKCS#15 provide higher level assurance and reliability for
managing and manipulating private-keys (Benantar, 2001). Note that PKCS is stand for
Public-key Cryptography Standard. PKCS#1 to PKCS#15 can be downloaded from
http://www.rsasecurity.com/rsalabs/pkcs/. Storing a private-key on a smart card is another
option as a smart card is designed to be tamper-resistant. This method is considered the best
option.
Storing a private-key on a desktop is practical since there is no additional device needed.
However, the key is vulnerable to theft whether through hacking or direct breaking into the
desktop. Storing a private-key on a smart card is more secure, but an additional hardware, a
smart card reader, needs to be installed. Also, if the smart card is broken or lost, a new card
need to be issued, this may create an administrative burden. Which one is the most
appropriate? The answer is really depending on the level of security and risk tolerated. For
low value transactions, storing private-keys on desktops with the available encryption
technology is appropriate.
However, to avoid financial loss if things go wrong for using digital signatures in an open
network such as the Internet, additional measures must be introduced. Kaner [14] suggested
additional risk management must be introduced such as delivery location, credit limit,
transaction limit, pattern analysis for frequency use and some others. McCullagh [16]
proposed trusted computing systems to provide trusted environment for digital signatures so
that both parties (the signer and the recipient) are in equal position to prove their respective
case.

DIGITAL SIGNATURES: TECHNOLOGY, MANAGEMENT AND APPLICATIONS

199

4. SOME DIGITAL SIGNATURE APPLICATIONS

There are many digital signature applications such as secure e-business transactions,
intranet/extranet access authentication, e-mail authentication, enhancing of existing payment
systems, software distribution, and digital cash.
The majority of current digital signature applications are used to secure business transactions
and processes. A survey conducted by Shiralkar and Vijayaraman [22] on various modes of
business transactions indicates that majority of digital signatures are developed to be used for
security of electronic transactions, followed by combination of security and authentication
and then finally for merely authentication.
Digital signatures can replace hand-written signatures for signatures in electronic contracts.
Electronic contracts are particularly useful for relatively inexpensive items such as airline
tickets [10].
Securing email using PGP (Pretty Good Privacy) has been around for some time. Using PGP
software one can digitally sign a message and send the message securely through the
Internet. PGP does not rely on public-key infrastructure since PGP is based on a one-to-one
relationship between a sender and a receiver.
Applying digital signatures on many-to-many and opened relationships in e-commerce is still
facing problems since a digital signature cannot replace trust. Business transactions take
place mainly based on trust and are conducted on a one-to-one and closed relationship [11].
Even using credit cards the relationship is basically a one-to-one and closed relationship
between a person with a credit card company and between a merchant and a credit card
company. Unless a CA is a financially strong company and willing to take risk like a credit
card company, many-to-many and opened relationships transactions are not going to flourish
with digital signatures.
Enhancing existing payment systems with digital signatures such as introducing digital
signatures for payment using credit card on internet transactions is more practical than
implementing a completely many-to-many and opened transactions on the Internet. A good
example is the Secure Electronic Transaction (SET). SET protects payment information
based on authentication and encryption of payment information. Before a transaction happen,

200

MOHAMMAD NABIL ALMUNAWAR

a merchant and a cardholder authenticate one another using their digital signatures. A
merchant cannot see a cardholder's credit card number since the credit card number is
encrypted using a payment gateway's public-key.
Electronic money or digital cash has been developed to deal with payment of microtransactions or micro-payments since these payments are not cost effective using credit
cards. Electronic money is authenticated by the issuer's digital signature. The validity of
electronic money is guarded by a serial number. An example of electronic money was eCash,
electronic money that developed based on Chaum's blind signature [3;4]. Although eCash
was formally launched throughout Germany by Deutsche Bank 24 and it was offered to
consumers and merchants throughout Germany, eCash was unable to survive. Recently
quite popular electronic cash is Bitcoin 17]. Bitcoin (http://www.bitcoin.org) is a peer-topeer version of electronic cash that allows point-to-point direct payment without the need of
a third party/financial institution.
Another application is electronic checks. An example of e-check is NetCheque [18].
NetCheque (http://www.netcheque.com) relies on digital signature technology for issuing
and verifying electronic checks.
Another interesting application is XML digital signatures. Unlike HTML (Hypertext Markup
Language) documents which merely for the display purpose, XML (eXtendsible Markup
Language) documents can be processed electronically. XML has been widely adopted for
documents exchange over the Internet. Adding digital signatures as well as encryption
features to XML make XML documents can be used to support secure transactions over the
Internet.
XML signatures are digital signatures designed to secure XML transactions.

XML

signatures preserve all features of digital signatures such as authentication, security or

integrity and non-repudiation. However, XML signature is design to take advantage of
Internet and XML (Simon, Madsen, and Adam, 2001). XML signature is supported by XML
working group within World Wide Web Consortium (W3C). All documents related to XML
signature are available at http://www.w3.org/Signature/.

DIGITAL SIGNATURES: TECHNOLOGY, MANAGEMENT AND APPLICATIONS

201

CONCLUSION
Digital signatures are codes generated by a public-key cryptosystem by encrypting a digested
message using a private-key. Verification of a signature is done by applying the related
public-key to the signature.
Digital signatures are diametrically opposite to hand-written signatures and it preserves or
even offers better properties. It has an equal legal standing as the latter hand written
signatures as well. Many nations in this world have passed legislation on digital signatures.
Applying digital signatures on a one-to-one basis when parties involved know one another is
trivial. However, applying them in a large network, especially the Internet, is quite complex.
The problem lays on ensuring that a particular public-key really belongs to its owner and its
valid. This is the reason why a public-key infrastructure is needed. Another problem is the
possibility of disclosing of a private-key without the owner's knowledge. The technical
definition of non-repudiation can complicate if it is adopted in a digital signature law since it
will shift the responsibility of proving the signature to the signer.
Adoption of digital signatures in many-to-many and opened relationships on the Internet
may take some time, however digital signatures have been adopted in supporting many oneto-one relationship transactions such as credit card payment using SET. There are many
applications of digital signatures ranging from traditional use of signature to digital cash.

REFERENCES
[1]

Bellare, M. and Rogerway, P. (1996), The exact security of digital signatures how to sign
with RSA and Rabin in EUROCRYPT, pp. 399-416.

[2]

Benantar, M. (2001), The Internet public-key infrastructure, IBM Systems Journal, Vol. 40 No.
3, pp. 648-665.

[3]

Chaum, D. (1983), Blind signature for untraceable payments in Advances in Cryptology

Proceedings of Crypto 82, Plenum, pp.199-203.

[4]

Chaum, D. (1992), Achieving electronic privacy, Scientific American, August, pp. 96-101.

[5]

Conry-Murray, A. (2001), Public-key infrastructure nuts and bolts, Network Magazine,

November 2001, pp. 46-51.

202

MOHAMMAD NABIL ALMUNAWAR

[6]

Diffie, W. and Hellman, M. E. (1976), New directions in cryptography, IEEE Transactions on

Information Theory, Vol. 22 No. 6, pp. 644-654.

[7]

Ellison, C. M., Franz, B., Lampson, B., Rivest, R., Thomas, B. and Ylonen, M. T. (1998) SPKI
requirements, SPKI certificate theory, simple public-key certificate, SPKI example. [online]
Available at: http://www.clark.net/pub/cme/html/spki.html. (Accessed 10 June 2006)

[8]

FIPS (1994). Digital Signature Standard (DSS). [online] Federal Information Processing
Standards
Publication
186,
May
1994.
Available
from:
http://www.itl.nist.gov/fipspubs/fip186.htm. (Accessed 4 April 2006)

[9]

FIPS (1995). Secure Hash Standard. [online] Federal Information Processing Standard
Publication 180-1, April 1995. Available from: http://www.itl.nist.gov/fipspubs/fip180-1.htm.
(Accessed 4 April 2006)

[10] Freeman, E.H. (2004), Digital signatures and electronic contracts, Information Systems
Security, May/June, pp. 8-12.
[11] Gladman, B., Ellison, C. and Bohm, N. (1999) Digital signatures, certificates and electrnonic
commerce [online]. Availabe at: http://iya.com/bg/digsig.pdf (Accessed 10 April 2006).
[12] Housley, R., W. Ford, W., Polk & Solo, D. (1999) Internet X.509 public-key infrastructure
certificate and CRL profile [online]. Availabe at: http://www.ietf.org/rfc/rfc2459.txt (Accessed
4 April 2006).
[13] Kalaski Jr, B.S. (2001), RSA digital signatures, Dr Dobbs Journal, May, pp. 30-36.
[14] Kaner, C. (1997). The insecurity of the digital signature [online]. Available at:
http://www.badsoftware.com/digsig.htm (Accessed 4 April 2006).
[15] Kuechler, W. and Grupe, F. H. (2002), Digital signatures: a business view, Security
Architecture and Models, March/April, pp. 23-35.
[16] McCullagh, A. and Caelli, W. (2000), Non-repudiation in the digital environment',
Firstmonday,
(5):8
[online],
Availabe
at:
http://firstmonday.org/issues/issue5_8/mccullagh/index.html [Accessed 14 April 2006]
[17] Nakamoto, S. (2009). Bitcoin: a peer-to-peer electronic cash system [online]. Avaliable at:
http://bitcoin.org/bitcoin.pdf (Accessed 24 December 2012]
[18] Neuman, B. C. and Medvinsky, G. (1995), Requirements for network payment: the
NetChequeTM perspective in IEEE Compcon95: Proceedings of IEEE Compcon95, San
Francisco, USA.
Available at: http://clifford.neuman.name/papers/pdf/9503_netchequeneuman-medvinsky-compcon95.pdf. (Accessed 24 December 2012)

DIGITAL SIGNATURES: TECHNOLOGY, MANAGEMENT AND APPLICATIONS

203

[19] Rivest, L.R & Lampson, B. (1996) SDSI - A simple distributed security infrastructure [online].
Available at: http://research.microsoft.com/users/blampson/59-SDSI/Postscript.ps. ( Accessed 4
April 2006)
[20] Rivest, L.R., Shamir, A. and Adleman, L. (1978), A method for obtaining digital signatures and
a public-key cryptosystem, Communications of the ACM, Vol. 21, No.2, pp. 120-126.
[21] Schneir, B (1991), One-Way Hash Function, Dr Dobb's Journal, September, pp. 148-151.
[22] Shiralkar, P. and Vijayaraman, B.S. (2003), Digital signature: application development trends
in e-business, Journal of Electronic Commerce Research, Vol. 4 No. 3, pp. 94-101.
[23] Simon, E., Madsen, P. and Adams, C. (2001). An Introduction to XML Digital Signatures
[online]. Available at http://www.xml.com/pub/a/2001/08/08/xmldsig.html (Accessed 19
October 2006)
[24] Silverman, R. D. (2002). A cost-based security analysis of symmetric and asymmetric key
lengths,
RSA
Security
Bulletin,
No.
13,
April
[online].
Availabe
at:
http://www.rsasecurity.com/rsalabs/bulletins/bulletin13.html (Accessed 4 April 2006).
[25] Wang,Y (1998). SPKI [online]. Availabe at:
http://www.hut.fi/~yuwang/publications/SPKI/SPKI.html (Accessed 4 April 2006).

Mohammad Nabil Almunawar

Faculty of Business, Economics & Policy Studies,
Universiti Brunei Darussalam,
Jalan Tungku Link,
Gadong BE1410
Negara Brunei Darussalam