Andrew Finnell <[EMAIL PROTECTED]> writes:
> 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.
Well, there's "normal" and there's "most secure". Normal is to
store them in a PEM file encrypted under a password. Essentially
you take the password and run it through a hash function to get a
DES (or better yet, 3DES) key. This has a number of problems,
the two foremost being:
(1) Someone who gets your .pem file can try to password
search to get the private key. This won't work if you've
used a strong password but those can be hard to generate and
remember.
(2) Someone who breaks into your computer while it's running
the server can the private key out of memory.
The "most secure" way is to store the keys in some hardware
device which is designed to let you perform public key ops
with the key but never to give up the key -- and to zero itself
if you tamper with it. They can also be designed to be unusable
without a passphrase.
This material is covered in section 5.11 of "SSL and TLS", pp. 146-154.
> 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.
Ok. Roughly speaking there are two ways to get a certificate: (1) issue
it yourself and (2) use CA. Issue it yourself means that you create a
"self-signed certificate" when you generate your key. Using a CA means
you generate a "certificate signing request", give it to your CA
and the CA gives back a certificate. You then have to load that
certificate into your software.
A degenerate case of a CA is a "local CA" in which you run your own. You
might use a private protocol between you and your CA and not be able
to support CAs run by third parties such as VeriSign. (For instance, your
system might have custom extensions that need to be in the certs).
What this question _might_ mean is can you use certificates issued by
a third party CA.
> 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?
Yes. See "SSL and TLS" S 9.14 pp 307-314.
> 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?
The client ALWAYS needs to check this stuff. The server might want to
check it's own certificate in order to detect misconfigurations but
it's not really necessary.
> 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.
Most of this material is covered (though I want to talk more about
real world certificate policy in 2ed).
The following material is all covered in "SSL and TLS", mostly in
Chapter 1,3, and 4 but I'll take a stab at summarizing.
> 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?
Not quite. Say we have some message (M) that we want to send from Alice
to Bob. If we use ordinary (symmetric) cryptography then Alice and Bob
need to share a key, K, and we do:
Ciphertext=Esymmetric(K,M).
If we use public key (assymetric) crypto then Bob has a Public Key
(Kpub) and a Private Key (Kpriv). Alice can send a message to Bob that
only Bob can decrypt (even Alice can't) doing:
Ciphertext=Ersa(Kpub,M)
Bob can decrypt it doing:
M=Drsa(Kpriv,Ciphertext)
However, for a number of technical reasons (mainly performance)
RSA isn't really suitable for encrypting actual ASCII messages.
Instead you encrypt symmetric keys with RSA and then use the
symmetric keys to encrypt the message.
E.g.
Ciphertext=Ersa(Kpub,Ksymmetric) + Esymmetric(Ksymmetric,Message)
RSA can also do another trick, which is that if you encrypt
with the private key you get something that can only be decrypted
with the public key (and could only have been generated with the
private key). This can be used to prove that the sender had the
private key and is called a digital signature.
I.e.
Signature=Ersa(Kpriv,Message)
To verify you check to see if:
Drsa(Kpub,Signature) ?= Message
Again, for technical reasons you don't want to sign the whole
message. Therefore you use a "message digest" (MD5, SHA, whatever).
I.e. you do:
Signature=Ersa(Kpriv,MD5(Message))
DH is a special purpose algorithm that can only be use to exchange
keys (not quite the way that RSA can, either, but close enough for this
discussion).
DSS is a special purpose algorithm that can only be used for signing.
This is why DSS and DH are often used together.
> So basically RSA does two things while DSS
> relies on DH to be complete?
You could put it that way.
> 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.
No. The session key is known to both parties, it has to be.
The way DH works is that each side takes the other sides DH exponent
and combines it with its own to form a common shared key.
> It uses DSS for public key encryption,
It uses DSS for authentication (i.e. digital signature). I.e. you want
to know that the person you are communicating with is who they say they are.
> DES for the actual data stream. I
> don't know what CBC3 means.
DES-CBC3 is one block. It means Triple-DES in CBC mode.
> 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.
You're not encrypting the message with SHA. You're computing a
Message Authentication Code (MAC) with SHA (actually with HMAC-SHA
which is a specific use of SHA). There are two ideas here:
(1) Keep the data secret. This is done by DES (or, as I said, 3DES).
(2) Keep the data from being tampered with. This is done by SHA.
> 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?
No, actually the exact opposite. 3DES is much faster but it can't do
something that RSA can do.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
Author of "SSL and TLS: Designing and Building Secure Systems"
http://www.rtfm.com/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
