Take the 2-minute tour ×
Web Applications Stack Exchange is a question and answer site for power users of web applications. It's 100% free, no registration required.

What encryption is used when my password is sent across in gmails/when I do online banking? RSA? DSA? Public-private key encryption?. In key encryption, which entity is assigned a public/private key? Does each unique machine with unique MAC address has a unique public/private key? Does each instance of browser have unique key? Does each user have unique private/public key? How does session key come into picture? How do machines receive their keys?

share|improve this question
add comment

migrated from superuser.com Feb 13 '11 at 13:53

This question came from our site for computer enthusiasts and power users.

4 Answers

There is a Security Now podcast episode that walks through the details of SSL/TLS.

Link to MP3: http://media.grc.com/sn/sn-195.mp3

Link to transcript: http://www.grc.com/sn/sn-195.htm

Short answer: The encryption scheme used is decided at the beginning of the session after both the client and the server has listed which encryption schemes they support.

The unique private key is assigned to the server. The browser only ever gets the public key, and all the different users get the same public key. (Usually; something like gmail is probably hosted on multiple servers all with their own private/public keys)

share|improve this answer
add comment

To have a secure two-way communication, parties either need a shared secret or must have a private/public key pair. When you connect to your bank's website TLS is used. In the typical case the asymmetrically encrypted channel is used to establish a symmetrically encrypted channel.

When establishing a communication channel (called "handshaking"), your browser connects to the remote server and asks for its public key and a certificate that proves that this key belongs to the host. The certificate is digitally signed by a certificate authority (CA). The list of trusted CAs (with their own certificates) is shipped with your browser so it can check the received cert. At this point the browser might display a warning if something is not o.k. with the cert. If the server's public key is accepted then an encrypted message is sent which can only be decrypted by the server's private key to establish that the server really has the correct private key.

The private key belongs to that server only, independent of the MAC address of the physical/virtual computer because TLS encrypts at the application layer in the OSI model. Consider a simple example: if a single ip address belongs to multiple domains, e.g. serv1.example.com and serv2.example.com then they must share the certificate because the encryption hides the host name in the communication, so only an ip address is available. Thus if the cert is issued for serv1 then your browser detects an invalid cert if you want to connect to serv2.

After the server's identity has been established the actual communication uses a symmetric encryption scheme where the key (the session key) is randomly generated by a cryptographically secure algorithm. This is common practice (e.g. Kerberos also uses symmetric encryption with session keys) because this decreases the exposure of the private key (increased security) and symmetric encryption is much faster (increased usability).

The actual algorithms used are decided during the handshake process by your browser and the server. The browser receives a list of supported algorithms from the server and picks the strongest it can support. In more complicated cases the server might ask for a certificate from the browser to authenticate the user. For example myopenid.com allows authentication by a certificate instead of a password. In this case your certificate must contain a hidden part that is only known by you and it can be established that this hidden part is consistent with your cert stored in the browser. This hidden part is typically the private key of a public/private pair.

In the case of the Apache web server the public/private key pair is generated by openssl. This only allows encrypted communication but no server authentication (browsers complain). Then you can go to a CA and get a certificate for you server (for a fee).

Sources, recommended reading:

share|improve this answer
add comment

I also think it is sent over HTTPS, HTTP with SSL/TLS. The way it works is that TLS does a handshake. It send the client a CipherSuite, then the client choses the best it supports and notifies the server, then the server sends its public key to client.

Here session key comes to play. client generates a random number and encrypts it usign the server public key. Only the server should be able to decrypt is using its private key. from this moment on this number will be their private key and they will use private key encryption since it is faster.

Both client and server can have public/private key. But for making the key in symmetric encryption the server's(e.g. gmail, bank,..) public key is used.

share|improve this answer
add comment

It's usually sent over SSL, which negotiates a session key (symmetric) over a connection secured by public/private key (asymmetric). You password is sent using the session encryption, as asymmetric is very computationally expensive.

share|improve this answer
    
So when establishing the symmetric session key using asymmetric encryption, which entity has unique private/public key? Each computer with unique MAC address? –  xyz Feb 13 '11 at 10:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.