The wiki page on Cryptography gives you some basic ideas already.I will just try to elaborate a bit more to explain the topics at a very introductory level.
In the earliest days of Cryptography, it was all about Symmetric Cryptography wherein a private key was used to encrypt data at the sender’s end and decrypt data at the receiver’s end, so that confidentiality(one of the CIA Triad) of the over-all system is maintained.But integrity(another CIA Triad) was missing at it’s core(availability, which is again another CIA Triad is more of an Application Specific stuff and related issues like Denial Of Service can be handled using techniques like Throttling).Also key(the private key) management was an issue.Imagine ways to securely sharing the private key with your client(s) – could be via emails, over the phone or you might be using a very faithful parrot/pigeon 🙂 or some other weird way – but is that a feasible way if it’s a very large system with huge number of senders and receivers? Nope, not at all.Key management of Symmetric Cryptography sucks for very large systems wherein there are hell lot of systems and hell lot of clients trying to communicate with those systems.
The limitations of the Symmetric Cryptography(as mentioned above) paved the way to Asymmetric Cryptography(aka Public Key Cryptography) wherein both public and private keys are used to share some data over the wire between the sender and the receiver.These keys are generated mathematically using Number Theory techniques based algorithms and are always used in pairs – if the public key is used to encrypt the data then the private key is used to decrypt the data and vice versa.Also, most of the algorithms allows such a pair to be generated only once which is a globally unique pair.
But how does Asymmetric Cryptography take care of Confidentiality and Integrity.Well, let’s have a look at that –
- Confidentiality -> First of all, we need to understand who should generate the keys to encrypt or decrypt the data – the sender of data or the receiver of data? Well it turns out that in real world systems, the receiver(e.g some Web Services Provider) generates the pair(both public and private keys) and sends the public key over the wire to the client(s) and then the client(s) use this public key to encrypt the data and send the encrypted data back to the receiver which uses the earlier generated private key to decrypt the encrypted data.So if there is a (wo)man in the middle attack, (s)he wont be able to understand the data that is going over the wire since (s)he doesn’t have the private key to decrypt the data and that’s how confidentiality is achieved.But why is it not the other way around i.e. why not the keys are generated by the client(s)? Well, I am not going to go any deeper on this since this can be a good exercise for the reader. Just think for sometime and I am sure you will be able to get the answer.
- Integrity -> Whatever mentioned above regarding Confidentiality doesn’t let the (wo)man in the middle to understand the data but (s)he can tamper the data due to which even if the receiver is able to decrypt the data that won’t be the client(s)’ intended data to share with the receiver which is a major problem.So how does Asymmetric Cryptography handles this problem of Integrity? Well, say hello to Hashing.The client(s) separately hashes the data and encrypts the data and sends both the hash and the encrypted data over the wire which the receiver on receiving decrypts the data and hashes the decrypted data at its end and checks if the hash it has generated is the same that was sent by the client(s) and if it matches, everything is fine else it’s alarming and thus integrity of the over-all system is maintained. In-fact the Hashing approach could have been used for Symmetric Cryptography as well but the earliest techniques of Symmetric Cryptography never used that but in recent days most Symmetric Cryptography techniques uses this Hashing technique for integrity.
But is there still some flaw with whatever explained till now? What about the public key shared across the wire? Is there any loop hole there?Think like a hacker. Think before reading further.
Yes, there is a loop hole.What if the the hacker((wo)man in the middle) traps the public key (can be easily done since it’s publicly exposed to everyone over the wire) and replaces it with it’s own public key and so when it receives the encrypted data from the client(s), it will use its own private key(generated by the hacker while generating the public key) to decrypt the data and that’s a very serious problem.So in this case, the client(s) are not sure if they are using some genuine and valid public key which they can believe/depend on.So how do we tackle this problem? Dont worry :)! Digital Certificates are there to rescue you from this problem.
So how does a Digital Certificate ensure that the public key is not misused by some hacker and it’s a valid one? Let’s see how.
There are lots of CAs(Certificate Authorities) (e.g. Verisign) which issues Digital Certificates to systems on request of the system owners(but after doing all sort of needed verification/cross-checking about the system and their owners).The system owners shares the public key(alongwith sharing some other security attributes used by the system) with the CA and then the CA uses this data to generate the Digital Certificate which is a combination of encryption of this data(encrypted by using a private key) and a digital signature(which is created by hashing the public key shared by the system with the CA and then applying another private key encryption on the hash).Now such systems doesn’t send the public key directly over the wire to it’s client(s) but uses Digital Certificates to share the public key with the client(s).The client(s) communicates with the CA to get the public key to decrypt the Digital Certificate to get the actual public key to be used for encrypting the data to be sent to the systems/receivers.For more info on Digital Certificates refer Understanding Digital Certificates.
So now, I have another question.Where does https using SSL/TLS comes into picture amongst all these? To explain this I have another question – how does the systems communicate/negotiate with their clients about what algorithm is going to be used for encryption using public key(needed for Confidentiality as explained above) and which Hashing algorithm is going to be used(needed for Integrity as explained above)? That’s where SSL/TLS comes into the picture. SSL/TLS serves as the communication/negotiation medium between the systems and their clients as to which algorithms are to be used for confidentiality and integrity which are mandatory for the to and fro secure transmission of data between the systems and their clients.
Well that’s all for now.I hope I have been able to explain the Basics of Cryptography in a simple way so that it’s understandable even by an amateur/novice(just like me 🙂 ) in this field.There are some advanced topics like Certificate Chaining, Symmetric Encryption for Session Data, Symmetric Encryption for Streaming Data etc which are beyond the scope of this introductory article on Cryptography(by the way, Symmetric Cryptography is not extinct but still has lot of applications).
N.B. -> For further study in Cryptography (& Information Security in general), refer the courses offered by Stanford University on Computer Security.