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)?

To achieve Data-Integrity and Authentication we use 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:

hash-integrity-01

  1. Message is Hashed by a hashing algorithm (SHA1, MD5, etc.)
  2. Both the message and the resulting hash are sent to Simon
  3. Simon hashes the message using the same algorithm
  4. 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:

pub-key-encryption-02

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!

pub-key-enc-01

Recipient’s Authenticity: The message is encrypted with Simon’s public key; anyone else could send a message to Simon using his public key. However, only Simon will be able to read the message – it can only be decrypted with the associated private key, no other!

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:

  1. Simon is certain the hash was sent by Jack
  2. 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. 

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

hash-integrity-03

  1. Message is Hashed by a hashing algorithm (SHA1, MD5, etc.)
  2. Jack signs the Hash with own private key
  3. The unencrypted message along with the digital signature are sent to Simon
  4. 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)
  5. Simon compares both hash values to validate data-integrity; by decrypting the signature with Jack’s public key, authentication is also validated
Note that, by digitally signing a message does not imply encryption of the actual message which in fact, is optional.

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

hash-integrity-4 

  1. Message is Hashed by a hashing algorithm (SHA1, MD5, etc.)
  2. Jack signs the Hash with own private key
  3. The message and the signature are packaged together and encrypted with Simon’s public key
  4. The encrypted message (which now includes the digital signature) is sent to Simon
  5. Simon decrypts the message with his own private key
  6. The unencrypted message along with the digital signature are revealed
  7. 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)
  8. 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.

We make sure public key are exchanged securely by means of Digital Certificates, as we’ll see in Part III.

 


Thank you,
Signature
View Rafael A Couto Cabral's profile on LinkedIn



Comments are closed.