sanfran83
asked on
SSL hand shake
1)When a gmail user opens gmail dot com in his web browser, the user is directed to https.
2)now the ssl hand shake goes through process-
first the gmail client says hello
gmail server says hello
gmail server sends the public key certificate
gmail server hello done
client key exchange
client change cipher spec
client encrypted handshake message
server change cipher spec
server encrypted handshake message
now the client uses the public key to encrypt the message it sends to gmail server and gmail
server uses his private key to decrypt the message.
My question is, which key gmail server is going to use to encrypt the message( his private or public key)
and can any one explain the things happening in each of those 9 process.
2)now the ssl hand shake goes through process-
first the gmail client says hello
gmail server says hello
gmail server sends the public key certificate
gmail server hello done
client key exchange
client change cipher spec
client encrypted handshake message
server change cipher spec
server encrypted handshake message
now the client uses the public key to encrypt the message it sends to gmail server and gmail
server uses his private key to decrypt the message.
My question is, which key gmail server is going to use to encrypt the message( his private or public key)
and can any one explain the things happening in each of those 9 process.
Paranormastic
The answer to the primary question is: neither. The negotiated synchronous key will be used on both ends - the public/private key is not used past the process you just laid out.
I will post the breakdown of communications in the morning - if anyone else wants to jump on that feel free.
>>> My question is, which key gmail server is going to use to encrypt the message( his private or public key) and can any one explain the things happening in each of those 9 process?
The initial encryption/decryption takes place using Public / Private Keys, using which a symetric key is later exchanged and latter used for encrypting and exchanging the payload. Remember in case of pub keys crypto, always the pub key is used for encrypting and the private keys are used for decrypting.
How how SSL works with https refer to the following link:
http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
SSL Handshake:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzas.doc/sy10660_.htm
Hope this helps!
The initial encryption/decryption takes place using Public / Private Keys, using which a symetric key is later exchanged and latter used for encrypting and exchanging the payload. Remember in case of pub keys crypto, always the pub key is used for encrypting and the private keys are used for decrypting.
How how SSL works with https refer to the following link:
http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
SSL Handshake:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzas.doc/sy10660_.htm
Hope this helps!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Quick terminology:
Synchronous key/encryption - both sides use a preshared secret (a password) as the encryption and decryption method. Examples include RC-4, DES, 3DES, AES and many more. This is common for zip files, flash drives, etc. - you type a password to encrypt it and you type the same password to decrypt it.
Asynchronous encryption/public-private keyset - PKI / certificate stuff. A certificate represents the identity and is trusted by the client. The certificate contains information about the server's public key, which the client will then use to encrypt. The server is the only place where the private key should exist, and will be used to decrypt any encrypted message from the client.
Synchoronous is much much faster than Asynch since the bit lengths are typically shorter they require less computation - this also results in smaller sizes of the ciphertext. The security is in the secret key being secret.
Asynch is slower and requires much more CPU to do the calculations. Since half of the keyset is public, the key lengths are much larger to slow down potential attacks. The private key is the secure part and remains private on that server.
For SSL, email encryption, EFS, whatever - generically speaking the same type of process happens - you use the initially more secure asynch process to negotiate a common synch key and to pass the password, then everything is synch after that.
Synchronous key/encryption - both sides use a preshared secret (a password) as the encryption and decryption method. Examples include RC-4, DES, 3DES, AES and many more. This is common for zip files, flash drives, etc. - you type a password to encrypt it and you type the same password to decrypt it.
Asynchronous encryption/public-private keyset - PKI / certificate stuff. A certificate represents the identity and is trusted by the client. The certificate contains information about the server's public key, which the client will then use to encrypt. The server is the only place where the private key should exist, and will be used to decrypt any encrypted message from the client.
Synchoronous is much much faster than Asynch since the bit lengths are typically shorter they require less computation - this also results in smaller sizes of the ciphertext. The security is in the secret key being secret.
Asynch is slower and requires much more CPU to do the calculations. Since half of the keyset is public, the key lengths are much larger to slow down potential attacks. The private key is the secure part and remains private on that server.
For SSL, email encryption, EFS, whatever - generically speaking the same type of process happens - you use the initially more secure asynch process to negotiate a common synch key and to pass the password, then everything is synch after that.
ASKER
Thanks!