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
-----Original Message-----
From: Neff Robert A [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 06, 2001 10:20 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Cryptology Questions
hmmm...a tall order for us busy folks...but I'll help you out some.
1. Provided you are using a "strong" password to encrypt your key when using DES-CBC
you are pretty secure. Remember that if I can get access to, or copy, your .pem file from
off your machine I can run a dictionary attack against it, searching for your encryption
password. If I find that, I can impersonate you.
2. Importing a certificate to me sounds like you are being asked if you are adding the
cert to either your browser's trusted store or your server's cert chain. Some additional
info would help clear that up a bit.
3. First, It is very important that, when validating a cert, you first check that the issuer of
that cert is trusted by you. OpenSSL does this rather easily for you, once you've informed
it of the CA certs you trust. You must do this because I can easily create a certificate
containing www.verisign.com as the issuer but would have to somehow convince you
to store my fake CA cert within your store. The entire issue of trust within the PKI
framework begins with the CA certs you trust. If you don't understand this completely,
please read up more on this topic at either Verisign's or RSA's web site. They have
decent tutorials on PKI.
Second, you then check that the cert has not expired. The notBefore/notAfter time
periods contained within the cert indicate what period of time the cert can be valid.
Of course, this is how the major CA's make their money, by limiting this period to
usually one year from issuance.
Third, you check the CN of the cert to ensure that it is indeed the site you are intent
on conversing with.
You can do additional checks if you wish to enforce certificate extensions. However
I've not had much experience using those so I'll defer to others...
RSA is an algorithm create to use a public/private key pair where, if using one key for
encryption, you use the other for decryption. If I know your public key, I can encrypt
data and send it to you, confident that ONLY you can decrypt it. However, it is a
slow algorithm compared to the symmetrical ones. That is why it is using only during
the SSL handshake for certificate verification and for transferring the SSL session keys.
It is not used for bulk data encryption like DES/AES/RC4/etc...
Regarding your thoughts on MD5, it is a Message Digest (the MD) of the content being
sent. It is not encrypting the data, per say, but rather creating a strong "checksum", if
you will, of the contents. You can then encrypt the MD with your private key and send
it along with your message. Upon receiving your message I would decrypt the MD
using your public key, re-compute the MD of the message sent, and compare it to
the decrypted MD. If they are identical, I know that a) the message has not been
tampered with and b) it could only have been sent by you since only you would have
the corresponding private key to encrypt the MD in the first place.
I know I've glossed over the many details here but hope this is the clarification you are
looking for. If not, ask again.
HTH,
Rob
-----Original Message-----
From: Andrew Finnell [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 06, 2001 9:17 AM
To: 'Openssl ([EMAIL PROTECTED])'
Subject: Cryptology Questions
Hi all,
I was wondering if someone could help me out. I have to speak with some cryptology experts later today and was wondering if some answers could be answered.
1. What is the normal/(most secure) way to store private keys and protect them?
Right now I store them in .pem format in a file and encrypt them with DES-CBC.
2. What does it mean if I need someone asks me if we support 'importing X.509 certificate from an external CA'. I thought that you just sign certificates with the CA not import them? Or am I missing something.
3. What is the normal/(most secure) way to validate the presented partners certificates when a SSL connection is established. Now my understanding was the defacto way was to include the ip/hostname in the CN? Is this correct and does it work both ways meaning. Can the server check to see if it's certificates have been move, i.e. if I copy public/private pairs from server a to server b, should server b check the ip/hostname to see if they really belong. And the client should check the certificate obtained from Server A, to see if it's really Server A correct?
Ok that's enough with the homework questions. Heh, it's not really homework but im sure that the answers are so easy that it seems like it. :) I bought Eric Rescorla's book 'SSL and TLS' and ive been trying to read that but I don't see where he goes into more detail about 'storing keys' and ensuring safety. Of course I could of just blown right by that chapter, I tend to read books backwards.
Now for my own interest. I see many names being thrown around. I'll tell you what I 'think' I know and please correct me if im wrong.
RSA is a public key cryptology. I take this to mean that the public and private keys ( i.e. certificate/key ) is encrypted over the wire with RSA? Actual application ( for my example we will say application ) data is encoded into a message and then encrypted with a Message Digest? Which can be either MD5 or SHA-1 for RSA but only SHA-1 for DSS. Now this is where I get confused. RSA is also used like DH, in that it's used to negotiate a session key? Is that correct? So basically RSA does two things while DSS relies on DH to be complete?
Let me see if I can translate this cipher: EDH-DSS-DES-CBC3-SHA. I take this to mean that the session key is negotiated with Emperhal DH meaning it's randomly generated on one side and not known by both parties. It uses DSS for public key encryption, DES for the actual data stream. I don't know what CBC3 means. But the Message Digest is SHA. Now what's the difference between encypting with a message digest with SHA but encrypting the data with DES? I thought the message was the data.
Also reading in Eric's book he says 1024-bit assymetric keys are about as strong as 80-bit symmertic keys. So why is assymetric used? I assume its because of performance. It would probably take to long if everything was encrypted with 3DES correct?
I do apologize for all these questions but I really want to learn SSL and in general Security and Cryptology inside and out but all the different encyptions are throwing me for a loop. I always just thought of cryptology in the terms of using RSA, DES or 3DES but I see there is a lot more to it.
THANKS!
- Andrew
-------------------------------------
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.
