Kyle is the best person to explain these things to you. However I will make an attempt. Please find answers inline.
--- michael Dorrian <[EMAIL PROTECTED]> wrote: > I make a client and server certificate and then sign > it with the root cert.Are these generated > certificates the public keys? Yes, certificates are nothing but public keys(in this case the client and server public keys respectively) and some other ancillary information signed by the private key of the CA(the root cert's private key in your case). Let us take the case of RSA for signing. Signing is nothing but the encryption with the private portion of the RSA keypair of the hash of the message in question. So in your case, the message consists of the client or server certificate(public key with ancillary data). So a hash is produced with the above message as input. SHA1 is the hash algorithm used for that. Once the hash is generated, it is encrypted with the CA's private key(root cert in your case). Lo, once you append this RSA encrypted hash, you have the signature. . I can attach small > data to an RSA key but usually RSA is not used for > actually encrypting the data. Is that right?. RSA or for that matter any public key encryption scheme is highly computation intensive and also unsuitable for messages of arbitrary length. The goal of all public key cryptosystems is either key exchange or key agreement and of course signing( or non repudiation). Now if you take any protocol like SSL or ssh , public key algorithms are used only for establishing a secret key between communicating peers, therefore a secret key(typically a DES3 or AES key) is encrypted with the peer's public key and sent across. This is called a digital envelope. Since the peer's private key is known only to the peer, only the peer can decrypt the secret key and hence now secret communications can happen between the peers. This is how SSL works, this is how ssh works, and this is how most other security protocols would work. > A specified cipher suite(e.g sha1 for hashing > etc.) is used. This is also where the actual data > you send's encryption scheme is also defined. Not > really sure about this?. SSL RFC defines certain "cipher suites". These are a combination of a particular public key algorithm, a particular secret key algorithm and mode, and a particular HMAC algorithm or a hash algorithm. We already saw how the first two are used. The HMAC algorithm is used to protect the integrity of the transferred messages. i.e, to prevent against malicious or accidental tampering of messages. Since hash algorithms like SHA1 or MD5 do not use a secret, anybody can modify the message along with the hash, that is why HMAC in which SHA1 or MD5 is used along with a secret key is used for protecting the integrity in SSL. Well, HMAC is not the only way to do it but ... > I also use SSL_OP_EPHEMERAL_RSA and > SINGLE_OP_SINGLE_DH_USE So by this i see i use > diffie hellman for key exchange and then using RSA > encryption for verification. The way this is done is > very vague. How are both of these used together > exactly?. I know how both the diffie hellman and RSA > algorithms work as public/private keys. I think that > in this case for verification a crytographic > hash(e.g sha1) is made of the generated certificates > and then this is used to match certs for > verification. Also i dont see exactly where my > public key and private keys on both the server and > client interact to encrypt and decrypt the data. Can > someone explain this better?. Well, I don't know much about what the ephemeral options do in SSL but AFAIK the word ephemeral is used for short lived security associations. So if you use an ephemeral key, its lifetime is very short. If I understand correctly the way SSL uses ephemeral keys is by using the SSL renegotiate option in which cipher suites are changed on the fly. Again this happens because once a secret channel is established, you can always change the secret keys used for a new set of messages. To answer the second part of the question, public and private keys really become irrelevant once the SSL session is established, since it is practically impossible and also unncessary to use them once a secret key is established. You can try encrypting a large buffer with RSA. Even on modern processors, it will take a huge amount of time. Again, this is because fundamentally public key cryptosystems work very differently from secret key cryptosystems. Public key cryptosystems use mathematically hard NP complete problems like large number factorization or discrete log problems(and also elliptic curve problems) to encrypt data. Whereas secret key cryptosystems are disarmingly simple in operation. They simply derive a key schedule(in case you are using a block cipher) from the secret key and transform input blocks by simple EX-OR and other table lookups. Actually it is more than this, but you can think of secret key encryption as mere transposition and substitution. Also this is what explains why an RSA keysize of 2048 is roughtly equivalent to an AES keysize of 256 bits. Hope I haven't bored you. regards, Girish __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
