Dear kirley,
There is no need to use DigiSign or other commercial products. The
best cryptography today follows the standards established by the
OpenPGP Alliance, a non-profit consortium of leading security firms and
telecommunications corporations who wish to promote public technological
solutions for the privacy of all individuals. These standards are vetted
by many cryptographic experts employed by the member institutions and
by the public at large. Their open specification is what ensures their
security.
OpenPGP: About
http://www.openpgp.org/about_openpgp/
OpenPGP: Members
http://www.openpgp.org/members/
Many commercial public-key-encryption and digital-security software
packages, such as ArticSoft and PGP, are based on OpenPGP standards.
ArticSoft: Products
http://www.articsoft.com/products.htm
PGP: Home
http://www.pgp.com/
However, you can also obtain OpenPGP technology for free in equally
reliable if somewhat less user-friendly implementations.
One reputable product, called Gnu Privacy Guard or GnuPG, is available
for free as a commmand-line tool precompiled for Windows 95, 98, NT,
2000 and XP. After downloading the zip file, decompress it using WinZip
or a similar utility to gain access to the executable, called gpg.exe .
GnuPG: Downloads: Binaries
http://www.gnupg.org/(en)/download/index.html#auto-ref-1
GnuPG: Downloads: FTP: MS-Windows zip file
ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.2.5.zip
Before you go about setting up GnuPG and using it to digitally sign your
files to prove their authenticity, you should understand the fundamentals
of the process. The below text is taken from a public-domain web document
without copyright restrictions.
"Introduction
"A digital signature is itself simply a sequence of bits conforming
to one of a number of standards. It is the generation of those bits,
and their interpretation at some later time/place, and the cryptographic
protocols and algorithms which used to govern both which give a digital
signature bit sequence meaning in contrast to just any bit sequence.
"Most digital signatures rely on public key cryptography, and a basic
understanding of the principles of these schemes is required to understand
how digital signatures work.
"Operational outline -- public key cryptography
"The method depends on the fact that anyone can transform a message
into cyphertext using a public key, but that the 'matching' private
key is needed to reverse that transformation. The following is a very
brief outline.
"Consider Alice and Bob. Bob wants Alice (and other people, for that
matter) to be able to send secure secret messages to him. To permit
this, Bob (most carefully indeed) generates a key pair consisting of
two (mathematically) related "keys". One key is called the public key,
and the other, the secret or private key. In the most useful of these
algorithms, it is impractical, even for a well-funded organization, to
compute the private key from the public key (this is the private key /
public key property). Bob keeps his private key secret, and publishes
his public key (on his webpage, for example, or by sending it to a key
server, or by going to a key signing party).
"Alice (or someone else) retrieves Bob's public key (at the same party
perhaps) and, using it to control the appropriate encryption algorithm,
scrambles or encrypts the message. For quality algorithms (at least in the
belief of those well-informed on the subject), once encrypted using Bob's
public key, the cyphertext cannot be descrambled or decrypted without the
private key. Thus, no one who intercepts the cyphertext will be able to
read it, even knowing Bob's public key. When Bob receives the message,
he decrypts it using his private key (kept secret since generation time
and so known only to him). Therefore, the message will be secure against
the unauthorized, and Bob and Alice do not need a "secure channel"
to exchange a shared key.
"The above is a simple outline of the method, and does not deal with
the details of how the key pairs are generated, how they are applied
to encrypt and decrypt the message, and what prevents an attacker with
access to the scrambled message and the public key from retrieving the
unscrambled message or the secret key. All are critical to security in
that if any is done improperly the message is very likely to be readable
by someone other than Bob. See public key cryptography.
"Operational outline -- digital signatures
"Now consider a somewhat different circumstance, in which Bob wants to
send a message to Alice and wants to be able to prove it came from him
(but doesn't care whether anybody else reads it). In this case, Bob
sends a cleartext copy of the message to Alice, along with a copy of
the message encrypted with his private key (not the public one). Alice
(or any other recipient) can then check whether the message really came
from Bob by decrypting the cyphertext version of the message with Bob's
public key and comparing it with the cleartext version. If they match,
the message was really from Bob, because the private key was needed to
create the signature and no one but Bob has it. The cyphertext version
is Bob's digital signature for the message because anyone can use Bob's
public key to verify that Bob created it.
"More usually, Bob applies a cryptographic hash function to the message
and encrypts the resulting message digest using his private key. This
makes the signature much shorter and thus saves both time (since hashing
is generally much faster than public-key encryption), and space (since
even an encyphered message digest is much shorter than the cyphertext
version of the entire plaintext)."
Wikipedia: digital signature
http://en.wikipedia.org/wiki/Digital_signature#Operational_outline_.26mdash.3B_digital_signatures
So your first step is to generate two keys, one private and one
public. The GnuPG program will use your private key to digitally sign a
file that you wish to distribute, while the public key is made available
to everyone. Note that if you were to send your private key to a third
party, it would no longer be private and you would be compromising the
security of your distribution scheme.
That is why it is unwise to contract out the business of signing your
documents to an external company, never mind the exorbitant expense of
doing so. The online digital-signature service offered by AlphaTrust,
for example, costs $1.00 per document and $1.50 per signature, with a
monthly minimum of $250 a month.
AlphaTrust: PRONTO Online Signature Service
http://www.alphatrust.com/products/pronto/poss.asp
You are far better off doing it yourself for both financial and security
reasons.
To generate your public and private keys, you will want to pass gpg.exe
the --gen-key option, as described in the GnuPG manual. Note that where
they write simply gpg for the name of the program, you should write
gpg.exe in the Windows command line.
GnuPG Mini Howto: Using keys
http://webber.dewinter.com/gnupg_howto/english/GPGMiniHowto-3.html
The most efficient way to apply digital signatures is to pass gpg.exe
the --detach-sign option before the name of the file you wish to
authenticate. This results in a separate signature file alongside the
original. You distribute both of these to your users, who can then
use their own copy of GnuPG to verify the signature file using your
public key.
GnuPG Mini Howto: Signing and checking signatures
http://webber.dewinter.com/gnupg_howto/english/GPGMiniHowto-5.html
The signature file is sensitive to the slightest changes in the data
file. Therefore, each time you modify the data file, you must generate a
new signature file and distribute both simultaneously. Only in this way
does the signature get properly paired with the data you are distributing.
Remember, your clients will also need copies of GnuPG. A similar
requirement applies to all digital-signature schemes. Also bear in mind
that the cryptography is asymmetrical.
To recapitulate, you keep to yourself the private key with which only
you can sign a file. Everyone gets access to your public key, with which
they can verify that the file was indeed signed by you. Thanks to the
mathematical properties of the public-key system, there is no practical
way to deduce the private key from the public key.
I believe I have covered every point in your question. If you have any
difficulty with the instructions I have given above, or if you feel
that any part of my answer deserves amplification or elaboration, don't
hesitate to let me know through a Clarification Request so that I have
a chance to fully meet your needs before you assign a rating.
Regards,
leapinglizard |
Clarification of Answer by
leapinglizard-ga
on
04 Nov 2004 11:07 PST
That is correct. All digital-signature methods require that the user
have some means of applying your public key to the downloaded file.
There's really no way to get around this requirement, regardless of
the particular software package you choose.
Think about it this way: if I give you a file along with its
signature, surely you will not just take someone's word for it that
the signature is authentic, will you? To believe that the signature is
authentic requires the same trust as believing that the document is
genuine. In other words, there's no real advantage to signing a
document if the user has to take it on faith that the signature is
authentic. That's why the user needs a piece of software: by using
your public key to process the file, they can verify that you did
indeed sign it using your private key.
As a general rule, enhanced content requires that the user possess an
additional piece of software. If you wish to distribute Java apps, the
user must have a Java interpreter. If your web page is made with
Flash, the user's browser must have a Flash plugin. Your concern, of
course, is that public-key software is not nearly as commonplace among
users as Java interpreters and Flash plugins.
If you'd like a somewhat simpler solution that offers a measure of
security without requiring a very esoteric piece of software, you can
publish the md5 checksum of your file on a separate, more secure site
than the one from which your client would download the file itself. A
checksum is a kind of data signature that requires no keys, since its
value depends only on the content of the file. The md5 algorithm is
one of the more common ways of generating a checksum from a given
file.
If you publish a file on a public FTP server while its md5 checksum is
made available on a secure web page, your users won't have to fuss
with keys or elaborate software to verify whether the file has been
corrupted. Instead, using a small and simple graphical utility such as
WinMD5Sum or MD5summer, they generate a checksum on their copy of the
file and compare it against your published checksum.
CNet: WinMD5Sum 1.0: Download
http://www.download.com/SolidBlue-Win-MD5-Sum/3000-2381-10115916.html
MD5summer: About
http://www.md5summer.org/about.html
If the checksums match, then, under the assumption that a malicious
agent hasn't replaced both the file and the checksum with fake but
matching copies, your users can be confident that they have the
authentic file. Since a checksum is very small, you can much more
easily and cheaply publish it on a secure webpage than the entire file
itself. In this way, the checksum functions as a digital signature. If
the checksum is no more securely distributed than the file, then it
offers no additional security, and you'll need the heavy-duty
protection of public-key encryption.
Regards,
leapinglizard
|
