Aspects of Cryptography

There are four main aspects of Cryptography. In this article we would look into the importance of these aspects. The future articles would cover them in more details.


Confidentiality:

The message should be legible only to theintended recipient. For everyone else, the message should be indifferent than a completely random string.

Message confidentiality was the primary reason for the birth of cryptography.
The ancient Egyptian hieroglyphs are said to be the first known use of cryptography. The famous Caesar Cipher was used to encrypt communication between Julius Caesar and his officers. Multiple cryptographic systems were also developed during the Renaissance period, notably, the Vigenere Cipher.

But, no matter the system used, the purpose was always confidentiality of communication between the sender and the receiver.

Confidentiality is desired when sensitive data is being exchanged. In the days before the internet, the sensitive nature of the information was limited to the military and the government. But now, most of our online communication can be classified as sensitive. Banking transactions, medical records, government documents, business communication, and even most of our personal communication are in need of confidentiality. It is highly undesirable that anyone else except us and the intended recipient knows anything about the transmitted information.

This is also applicable to the corporate or very personal documents stored locally on our computers or smartphones, or in the cloud. These documents should remain private if the device is compromised, or even if the device gets physically stolen.

So, by maintaining confidentiality we protect our message from an evesdropper.

But what if someone totally intercepts the message and replaces the encrypted message with a completely different encrypted message? These type of attacks are also called the “Man in the middle” attacks, and, to protect from such attacks, we should introduce the aspect of Integrity.



Integrity:

The message is not tampered or altered, in storage or in transmission, without the alteration being detected.

For example, in Caesar’s case, it was mission critical that the messages reached his officers untampered or unaltered.  Even a small alteration in the message could have led to disastrous outcomes, and the world would have been a different place. (Did none of his enemies really thought about it?)

We can relate the same analogy to the banking transactions. Once we submit an instruction to pay $100 for a purchase, it should reach the banking system unaltered. The requester, the beneficiary, the transaction amount, transaction date, etc, should remain unchanged. A modification in any one of these parameters could produce potentially undesired results. (Well, honestly, I wouldn’t have a problem if one of Bill Gates’s bank transfers ended up in my account by mistake, but vice-versa is undesirable!)

The same is true for the files in a storage. The integrity of a file should be maintained from the moment it was stored, till the moment it was retrieved. And, if the file was altered, let’s say by a virus, the system should be able to recognize it and should not execute it.

Now, tampering is not always a result of an ill-intended effort, It can also happen due to system errors, or memory corruption. In fact, in the TCP/IP communication protocol used on the internet, message corruption is a very common phenomenon.

We will look into the details in future articles, but for now just understand that in the TCP/IP protocol, a long message is broken down into multiple small packets. These packets are then routed individually to the destination address. When the packets reach the destination they are stitched back together to recreate the original message. For recomposing the original message in its pristine form, it is obviously essential that the integrity of each packet is maintained all through the transit. Hence, the TCP/IP protocol is designed to recognize the corrupt or lost packets by verifying their integrity, and request them again from the sender.

So, by verifying message integrity we can assure that the message has reached us in the same form as it was when it was transmitted.

But, now consider a case that we receive a properly encrypted and verifiable message, which says that it was sent by one of our close friends, Charlie, and it asks us to transfer an amount of $100 to a bank account.
Could this message be trustworthy? Can we just take it for granted that it was really sent by Charlie, and transfer that amount?
You may say, well, the message was encrypted, and the integrity was also verified, how could it be wrong?
To explain this, we should now introduce the aspect of  Authentication.



Authentication:

The sender and receiver can confirm each other’s identity, and also the origin and the destination of the message

Now, let’s say that one of Caesar’s officers receives a message. The message states that it was sent by Caesar himself, and as expected it is properly encrypted. The officer was also able to verify the integrity of the message. So, as usual, he decrypts the message. It reads… “Fallback now! The enemy is winning! – Julius Caesar”

What should the officer do?
Immediately act on it and retreat?
Of course not! We may agree that the most logical first step would be to try and check the authenticity of the message. Interrogate the messenger and find out who he is, and who gave him the message.
Hastily acting on such an instruction could easily mean a dinner with the Lions, or… “for the Lions” I may say…

Applying this analogy to our banking transactions, when the banking system receives an instruction, it needs to verify that the instruction was in fact submitted by us.
Now, because we are banking prodigies, we already know that before we can submit an instruction, we have to first login to the system.
And, absolutely, this is one of the methods to provide Authentication.

When we login to the bank’s website, the system generates a session key and provides it to the client application, which would be the browser that we are using. After this, every transaction between the browser and the banking system is encrypted using this key.
So, now the transactions are all, encrypted, verifiable, and authenticated.

Cannot be any better! or is it?
No suspense in that, because we still have one more aspect to be revealed!

So, let’s say that the banking system receives a request from Charlie to transfer $100 to Bob.
The banking system runs all the tests for confidentiality, integrity, and authenticity, and makes sure that the message is real, and promptly executes the transaction.
Next day, Charlie visits the bank and starts complaining about the transfer and states that he had never requested any such transfer!

To handle such a situation, we should introduce Non-repudiation.



Non-repudiation:

The creator of the message cannot deny the ownership of the message, and refute his/her intention in the creation or transmission of the message.

Authentication and non-repudiation, are closely related, but still different.

Traditionally, in the world on pen and paper, the authenticity of a document is achieved using “signatures”, and proper analysis of a signature could also give enough evidence for non-repudiation. There are also other means such as notarization, and presentation of photo id.

But, in the digital world, we cannot use a physical signature. Anyone could copy/paste the signature and try to forge documents. After all copy/paste is the first thing we learn to do on computers!

Non-repudiation can be achieved by combining  Integrity and Authentication
One such way is public key infrastructure, which uses digital signatures and digital certificates for verifying the origin of the message.

So concluding, Confidentiality, Integrity, Authentication, and Non-repudiation form the basis of cryptography and can be used as a grading system for evaluating the strength of a cryptographic system.

In future articles, we would look into each of these aspects in detail.