In a part I I’ve briefly touched on the differences between Symmetric and Asymmetric key encryption; Ie’ve also touched on hashing and provided three examples of different encryption/decryption scenarios.

It became very clear in those that it is very easy to get trap into a false sense of security – we encrypt data, though we then need to make sure that decryption is only available to intended recipient (**confidentiality**). We also need to validate the sender (**authentication**). In some cases we can achieve confidentiality and authentication – but how ca we ensure data has not been altered (**data integrity)**?

**Digital Signatures**

I’ve mentioned before that *hashing** *techniques are used for data-integrity validation. The idea is rather simple: **Providing the same hashing algorithm is used by the sender and the recipient, the resulting hash will always be the same**, like so:

- Message is Hashed by a hashing algorithm (SHA1, MD5, etc.)
- Both the message and the resulting hash are sent to Simon
- Simon hashes the message using the same algorithm
- Simon compares his hash with the one received from Jack – should they match, the message has not been modified in transit

**Since the hash doesn’t not change, we can be certain that the message did not change either.**

What about **confidentiality** and **authentication**?

In Part I we saw that in order to achieve confidentiality, all we need to do is encrypt using either the private key, or the public key; it really depends on what your objective is – so let’s review this:

**Sender Authenticity**: The message is encrypted with Jack’s private key; Simon (or anyone else) can decrypts the message with Jack’s public key only. This also means that Simon can be certain the message is indeed coming from Jack – he wouldn’t be able to decrypt the message using any other public key!

The key idea here: **The Private Key provides authenticity! **

**The DIGITAL SIGNATURE**

Since *hashing *provides data-integrity and *public-key encryption *provides authentication*;* therefore* *it makes sense to use both so that:

- Simon is certain the hash was sent by Jack
- Simon is certain the data arrived untampered

**Jack could then encrypt the hash with its own private key – we say that Jack has signed the data. **

**digital signature**is therefore an encrypted hash of specific data or message.

- Message is Hashed by a hashing algorithm (SHA1, MD5, etc.)
- Jack
**signs**the Hash with own private key - The
*unencrypted message*along with the*digital signature*are sent to Simon - Simon hashes the message using the same algorithm and obtains
*Hash2 (a);*the digital signature is also decrypted using Jack’s public key – this reveals the original*Hash1 (b)* - Simon compares both hash values to validate
**data-integrity**; by decrypting the signature with Jack’s public key,**authentication**is also validated

If we do need to encrypt the message as well, the process changes slightly:

- Message is Hashed by a hashing algorithm (SHA1, MD5, etc.)
- Jack
**signs**the Hash with own private key - The message and the signature are
*packaged*together and encrypted with Simon’s public key - The encrypted message (which now includes the digital signature) is sent to Simon
- Simon decrypts the message with his own private key
- The
*unencrypted message*along with the*digital signature*are revealed - Simon hashes the message using the same algorithm and obtains
*Hash2 (a);*the digital signature is also decrypted using Jack’s public key – this reveals the original*Hash1 (b)* - Simon compares both hash values to validate
**data-integrity**; by decrypting the signature with Jack’s public key,**authentication**is also validated

A more literal example can be found here.

Through all these examples, we have been assuming that the public key has been successfully exchanged. But here is the thing: Even though the key is public, I still need to make sure that Jack’s public key is indeed Jack’s; the same applies in regards to Simon.

*Digital Certificates**, as we’ll see in Part III.*

Thank you,