Asymmetrical encryption

Symmetrical encryption requires the participants in the communication to use a shared secret key. Asymmetrical encryption does not require the sharing of keys. The process uses a public key to encrypt and a private key to decrypt in order to achieve privacy. Both processes are efficient but Symmetrical is fast as compared with Asymmetrical. In this discussion, you are going to explain the details of Asymmetrical encryption from the time the client issue a request for the handshaking to received the keys. Explain how are keys generated?

how are keys generated:

Rivest-Shamir-Adleman (RSA), El Gamal, Elliptic curve cryptosystem (ECC), Digital Signature Algorithm (DSA), Elliptic curve DSA (ECDSA) are some algorithms defined and accepted to be strong and difficult to crack considering the computation power available today. These algorithms define how keys(public/private) are generated. For example, RSA is based upon factors of large prime numbers; El Gamal is based upon calculating discrete logarithms in a finite field; Elliptic curve works uses factoring prime number based on elliptic curves similar to RSA but with less computation power.

How Asymmetrical encryption works: 

1. Achieving Confidentiality: client encrypt content with public key and send message to server, server uses private key to decrypt the message.

2. Achieving nonrepudiation: server encrypt message with private key, and send to client, client decrypt using public key, it verifies that right server sent the message. same thing happens in case of digital signature.

But here is the catch, server sends an encrypted message which is supposed to be decrypted using public key, but public key everyone knows. So, next routes (3 & 4) explained gives possible work around.

3. Achieving both together: We will still name one as client and the other as server. calling sender sender when it becomes receiver at a point creates confusion. Client encrypt message with his private key, his public key is with server too. After first encryption above, the cipher text is again encrypted using server's public key.  The resultant cipher text is sent to server. server decrypt using his own private key. now this result of first decryption is decrypted again using client's public key.

4. Getting more practical: Now practically, client may not have a private and public key combination. If named entity as client in point 3 is an actual server then point 3 makes a sense. But what if client is my desktop. So here is how we get more practical: During handshake, client may send a tiny bit of symmetric ‘magic word’ encrypted with public key (of server) - to the server. Now this symmetric ‘magic word’ is decrypted with private key (of server)  and stored with server too. All future communications between client and server follow point 1 and 2. but a slight change:

a) Now client encrypt actual text with ‘magic word’, then with public key (of server) and then send it to server, server decrypt it with private key (of server) , then decrypt with ‘magic word’ and then process.

b) Server first encrypt with ‘magic word’, then with private key  (of server)  and send to client, client now decrypt with public key  (of server)  and then with ‘magic word’.

Reference:

1. http://robertheaton.com/2014/03/27/how-does-https-actually-work/

2. Shon Harris Book

3. Peter H. Gregory Book

For Key generation - Which one is better?

There are two ways to look at it: CIA and cost.

Confidentiality may not be in pieces, either 0 or 1. Given that, no algorithm can be 100% full proof, but could be difficult and time consuming to break, we could only move towards perfection.

Diffie-Hellman is vulnerable to man in the middle attack, RSA is slow, but elliptic curves could give similar results with less computing power required.

So "which one is better" may be answered, in terms of key length, required to achieve a given security level. Better algorithm may be the one, which need smaller key to achieve same level of security. Reference: http://www.ijcscn.com/Documents/Volumes/vol5issue1/ijcscn2015050103.pdf, Page 21 , Table 1.