Mixing asymmetric and symmetric encryption with HMAC hash verification .NET

Introduction

In this post we looked at how to combine symmetric and asymmetric encryption in the same project to increase messaging security. Symmetric encrypt is quick but has the problem of distributing the public key. Asymmetric encryption solves the public key distribution issue but is in turn a lot slower. We can combine the two techniques where a one-time symmetric public key, also called a session key, is encrypted with the asymmetric public key so that it can be decrypted by the receiver who has access to the asymmetric private key.

The solution is OK so far, it is very difficult to find the right keys involved. Still we can do better and add some message verification. We want to be sure that the message hasn’t been tampered with on its way to us. The sender can hash the encrypted message and send it along with the other necessary properties to the receiver. The receiver can compute the hash on their side and verify whether the two are equal. We looked at a couple of hashing techniques in this post but those do not involve any cryptographic key. That means that an attacker can change the message, recalculate the hash and attach it to the message. The password-salted hash algorithm HMAC sounds like a better option. We looked at HMACs in .NET in this post and we’ll reuse what we learnt there.

The goal of this post is to build upon the mixed encryption demo solution we built previously and add HMAC hashing to the picture.

Read more of this post

Mixing asymmetric and symmetric encryption in .NET part II

Introduction

In the previous post we started working on a mixed encryption demo project. The goal is to show how the benefits of symmetric and asymmetric encryption can be used in a single encryption-decryption flow. Symmetric encryption is fast but key distribution is problematic. Asymmetric encryption solves the key distribution problem but is on the other hand slow. Fortunately we can use both at the same time for increased security.

Previously we built the encryption service components: the interfaces and their implementations. Now it’s time to connect them.

Read more of this post

Mixing asymmetric and symmetric encryption in .NET part I

Introduction

In this post we briefly went through symmetric encryption in .NET. We know that symmetric encryption requires a single cryptographic key for both encryption and decryption. The AES standard is the most widely used symmetric encryption and generally it’s very difficult to guess the right key for an attacker. Symmetric encryption is fast but key distribution is problematic since all parties involved in the encryption process must have access to it. If it is compromised then it can be difficult to revoke it and let all legitimate parties that things have gone wrong.

This post on the other hand discussed asymmetric encryption. With asymmetric encryption we don’t have a single key but a key-pair: a public and a private key that belong together. This means that they depend on each other. However, the private key cannot be derived from the public key. The public key can be distributed to anyone who wants to send us an encrypted message. We then decrypt the cipher text with our private key. The private key must stay with us. It can be stored as an XML string in a file or a database. Alternatively we can store it in the Windows key store. The most common implementation is the RSA standard. Therefore asymmetric encryption solves the key distribution problem. On the other hand asymmetric encryption is slow as it involves some very complex mathematical computations. Therefore it is not really a good option if long strings need to be encrypted or if data encryption is heavily used by an application even for short strings.

This is where mixed or hybrid encryption enters the picture which brings together the best of both worlds: the speed of symmetric encryption and increased security of asymmetric encryption. This is the topic of the present and the next post.

Read more of this post