Girish Venkatachalam <[EMAIL PROTECTED]> wrote:
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]
New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low rates.
