Title: RE: Cryptology Questions
Yes,
the digest is used to validate that the data wasn't altered. Remember that
anyone can calculate the digest of a message. If the digest wasn't
encrypted with your private key, then someone could change the data, recompute
the digest, and exchange the original digest with the newly computed one.
Encrypting the MD with your private key prevents that from occurring.
That, in a nutshell, is digitally signing a document.
Regarding key distribution, no one but the owner should have access to
the private key. What reason would the server have for sending a client
their public AND private key? To ensure confidentiality and integrity, the
key pair should (must?) be generated by the client. It is the job of the
CA to sign the certificate (which contains among other things the owner's public
key). The private key itself is not contained within the cert. You
should read up on certificate requests to clarify some issues. For
whatever reason, if you are attempting to generate and supply both keys to you
clients, you have to have a very secure environment. More problematic is
that, because you have both keys, I am not guaranteed that someone at your
company couldn't impersonate me if I were a client...
Certificates themselves are public. Anyone can, and
does, have knowledge of their contents. OpenSSL comes with some of
the major CA signing certificates in use. You will find them in the
openssl/certs directory. You indicate to OpenSSL which of these certs you
trust to sign other certs. You can obtain these certs directly from the
vendor if you don't trust the ones in the distribution. It is the public
key contained within these CA certs that is used to decrypt the MD of the server
certificate received during the SSL connection that was encrypted
(signed) with the issuing CA's private key. And yes, a possible
attack would be that someone could add their own version of a "verisign"
root cert to your store, hijack a DNS server to reroute your IP connection to
another server, then use that server to act as a proxy to the original
server. Fortunately, this is not an easy thing to accomplish since many
machines need to be compromised. The attacker would still not have access
to your private key though.
Sleep tight! hehe
Cheers,
Rob
-----Original Message-----
From:
Andrew Finnell [mailto:[EMAIL PROTECTED]]
Sent:
Thursday, December 06, 2001 10:40 AM
To:
'[EMAIL PROTECTED]'
Subject: RE: Cryptology
Questions
Neff,
Thanks for the quick response. You
actually helped me understand some aspects that I didnt truely understand
before. For example the message digest. I did not know it was a checksum to
validate that the data wasn't altered.
--- More questions( better questions I guess? )
Regarding brute force attacks on the
private key, what other mechanism is there to protect these keys and
distribute them for that matter. For instance is it valid to have a server
send a client it's public/private key pairs to use. Then reconnect the server
with those keys. The security would come into play because the client needs to
know the password to decrypt the private key that it was sent. Is this a good
way to distribute client public/private keys? Sneaker footing/emailing the
keys or methods that aren't "automated" or easy to use isn't really available
to me.
As for importing the X.509
certificate, I am focusing on adding it to the certificate chain. How are most
certificates stored? Is it just as simple as opening up the
certificate.pem(client cert) file and performing some openssl operations to
add a cacert.pem(server cert) to the chain? This seems to easy and to prone to
attacks. Anyone could just open the file and add there ca.
BTW, thanks for the help anyone can give me. I know everyone
is busy and I dont demand that people answer :) I just find that mailing lists
like these are full of people that have the answers.
-------------------------------------
Andrew T. Finnell
Software Engineer
eSecurity Inc
(321) 394-2485
***************************************************************** DISCLAIMER: The information contained in this e-mail may be confidential and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorized. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator.
