Encryption is the process of taking a message and scrambling its contents so that only certain people can look at your message.
Symmetric Encryption
Let’s take the example of Alice and Bob.
Alice has a sensitive document that she wants to share with Bob. She uses an encryption program to protect her document with a password or passphrase that she chooses. When she sends it to Bob, he needs to know the password or passphrase to open the document. Emailing it or mailing it, sending it through a text message has its own vulnerability and this is where asymmetric encryption comes into the picture.
Asymmetric Encryption
In this type of encryption, both alice and bob generate a private and public key. (RSA for example). Alice and Bob exchange their public keys with each other. (Mailbox address can be a public key while the mailbox key can be a private key).
Now when Alice wants to send Bob a document, she encrypts the document with bobs public key and sends it to him. Now since only Bob has its own private key, only he can open that document.
There is one more application to this. The scenario being if Alice encrypts a document with her private key and again encrypts with bob’s public key and sends it to bob, he can decrypt the document with his private key and again decrypt it with Alice’s public key.
This ensures that the message is not tampered with in anyway and also the sender of the message is someone you know. Alice and Bob, both know that nobody else can read the message, they both know that the message is come from each other and not an imposter, Examples: SSL, SSH, PGP or GPG, Bitcoin etc.
Digital Signature
If Alice wants to send a document by email to Bob but this time, there is nothing secretive about this document and if anyone reads it. There is no way she can sign this document so a software on Alice’s computer (SHA) prepares the digital signature. The purpose of this document is to generate a hash value of this document or also called as a digest. Hash values cannot be reverse-engineered i.e you cannot take a hash value and get the message.
Once the hash/digest is generated, Alice can encrypt the hash using her private key and now this encrypted hash is embedded inside the document to be sent. Alice now sends a copy of the signed document. Bob decrypts the digital signature using Alice’s public key. Once he decrypts it, he knows that the message came from Alice.
Bob now calculates a hash value of the document using SHA. If the hash value Bob calculates is the same as that sent by Alice, Bob will know that the message truly came from Alice.
Digital Certificates
But there is a limitation to this. Anyone could have been pretending to be Alice in the first place. Maybe an attacker could have generated key-value pair and be talking to bob since the beginning. This is where digital signature comes into the picture. For a fee, Alice can apply for a digital certificate from a well known and trusted party also called a Certification Authority.
As part of the process, Alice will generate the asymmetric pair of keys. She will then submit her public key to the CA along with various details (This is called as CSR or certificate signing request). The CA then verifies all information. Once verified, they send Alice a special type of file called a digital certificate which has an expiry date. Bound to this digital certificate is Alice’s public key. On these certificates is a copy of the public key of the CA who might issue (sign) your server certificate.
Now when Alice sends a signed document to Bob, she can send it along with the Digital Certificate to Bob or just store the Digital Certificate in a public place. Bob can then check the digital certificate and know if the document really came from Alice. In short, the CA is vouching for Alice that she is who she says she is.
(HTTPS) SSL on web browsers.
Before a browser and an HTTPS server can exchange data over an encrypted connection, they first engage in a process known as the SSL handshake. One important part in the SSL handshake is the sending of the server certificate to the web browser. It’s here when the Web browser is able to authenticate the identity of the server it’s connecting to.
As soon as the browser receives a copy of the server certificate, it checks which CA signed the server cert and then retrieves the CA certificate of that particular Certificate Authority. It then uses the public key on that CA certificate to verify the digital signature on the server cert.
Once the digital signature has been authenticated, the browser and server can proceed with the rest of the SSL process.