Saturday, June 20, 2015

Guide for building an Encryption Policy: Encryption Algorithms - part 2

In part one of this blog-series we talked about hashing. This part is all about encryption. I will talk about what encryption is so the general concept is known, but then I will move on to a summarized encryption policy.

The series of posts are divided over the following topics.

Encryption versus Hashing

Encryption is, unlike hashing, an algorithm that has a two-way street. You can actually decrypt your message (or file, or whatever you want to encrypt). Encryption does not have a hash like hashing does, so it does not guarantee integrity of your data. It does protect the confidentiality of the message though. Please do keep this in mind. If you want to have confidentiality of your data and you want to safeguard the data's integrity, you will need to use hashing in conjunction with encryption.

But that is not all. Besides confidentiality encryption can also secure its non-repudiation. Non-repudiation is the fact that a party cannot deny that it has executed an activity. This can be very important to increase your audit and logging data to forensics level. But non-repudiation does not come by itself, you have to do something for it which I will explain later.

An overview on Encryption

Encryption can be symmetric and asymmetric. Symmetric encryption can be based on either stream-ciphers, or block-ciphers. Asymmetric encryption is either based on discreet logarithms or based on factoring the products of large primes. See the figure below which displays this schematically.

Cryptographic Systems (CC)

Symmetric Encryption

Symmetric key algorithms use the same key in both encryption and decryption process. This technique provides confidentiality. It does not provide non-repudiation.


Stream-ciphers are based on generating an infinite cryptographic key-stream and it encrypts a bit or a byte at a time. Stream-ciphers is used when the amount of data that is being sent is unknown.

Algorithms (excluding niche variants, patented and specific use algorithms) that are stream-ciphers:
According to current standards (dated April 4th, 2016) are as follows.
  • Deemed insecure*:
    • RC4, Salsa20
  • Deemed secure, but uncommon:
    • HC-128, HC-256, Rabbit
  • Deemed secure and common:
    • ChaCha20
ChaCha20, HC, and Rabbit can have a variety of key lengths.
  • 128 and 256-bit
Full list of stream-ciphers can be found on Wikipedia.


Block-ciphers are roughly the same as stream-ciphers, but instead of using bits or bytes to encrypt it uses blocks of data. This is best used in situations where the amount of data to send is pre-known. There are multiple modes of block operations (to which I won't go in detail), but you can see the differentiation below.
Algorithms (excluding niche variants, patented and specific use algorithms) that are block-ciphers:
According to current standards (dated April 4th, 2016) the situation is as follows.
  • Deemed insecure*:
    • BlowFish, DES, MacGuffin, RC5, ThreeFish, Triple DES
  • Deemed secure, but uncommon:
    • CAST-128, CAST-256, RC6
  • Deemed secure and common:
    • AES, TwoFish
AES, CAST, RC6, and TwoFish can have a variety of key lengths.
  • 128, 192 and 256-bit
In any case, I would advice to go for the maximum here (whenever possible), which would be 256-bit. Although 192-bit should be enough also for the foreseeable future.

Full list of block-ciphers can be found on Wikipedia.

Asymmetric Encryption

Asymmetric has some form of a key-exchange with such a result that a different key is used to encrypt and decrypt a message. This technique provides confidentiality and non-repudiation. Confidentiality is provided when the sender uses the receiver's public key to encrypt the message. Non-repudiation is provided when the sender's private key is used to encrypt a message. If you need both confidentiality and non-repudiation the sender needs to double-encrypt the message with the private key of the sender and the public key of the receiver.

Key Agreement

Asymmetric uses a key agreement protocol to exchange the public keys between the sender and receiver of a message. There are a variety of key agreement protocols.
The most generally used protocol is the Diffie-Hellman Key Exchange protocol.


According to current standards (dated April 4th, 2016) the situation is as follows.
  • Deemed insecure*:
    • ECC, ElGamal, RSA (1024-bit)
  • Deemed secure, but uncommon:
    • RSA (3072-bit)
  • Deemed secure and common:
    • RSA (2048-bit)
RSA can have a variety of key lengths.
  • 1024-bit (equivalent to 80-bit symmetric keys)
  • 2048-bit (equivalent to 128-bit symmetric keys)
  • 3072-bit (equivalent to 256-bit symmetric keys)
In any case, I would advice to go at least for the 2048-bit variant of RSA. RSA with 1024-bit key should be prohibited and with sensitive data the key should be 3072-bit.

The Security Policy should be...

  • Symmetric Encryption
    • Stream-ciphers
      • None (due to patenting).
    • Block-ciphers
      • AES: at least 192-bit key-size, but preferably 256-bit
      • TwoFish: at least 192-bit key-size, but preferably 256-bit
  • Asymmetric Encryption
    • Key Agreement: Diffie-Hellman
    • Algorithm: RSA, at least 2048-bit key-size, but preferably 3072-bit.


It has become quite a post, although in the end the policy is relatively small. In the next posts I will talk about some implementation guidelines of Encryption in the next post. In the last post a will gave a proper summary of everything I will discuss in all posts in a readable view.

What is your point-of-view on this topic? Do you see any errors or do you have any questions? Please do comment and let's learn from each other!

*) Insecure can mean totally insecure, or 'only' when certain terms are met that the algorithm gets insecure. It can also just be a theoretically insecurity rather than a practical one. The main message here: if you want or need to use this algorithm proceed with extra caution and testing.

This post has the tag: update, meaning it will be updated when new information becomes available and/or relevant.


Post a Comment