Monday, June 15, 2015

Guide for building an Encryption Policy: Hashing Algorithms - part 1

Are you a Security Officer and familiar with the question what is the baseline or policy for encryption? Or are you an engineer who has asked that very question? Or are you a power user that wants to learn more about setting up an encryption policy? As an IT Security Officer I have faced a similar question in the past, and I will try to answer it in this serie of blog-posts. Keep in mind that I talk mostly about the what here, not the how.

I have searched online allot about this topic and I hope I curated the right bits of information. Have to say, good encryption books are expensive and its content are mostly very detailed. Besides that, it is still a rather complex topic to deal with because it has many angles to approach it. In any case, always consider the protection of data first, before jumping to a solution like encryption. There are more ways to safeguard data and encryption just might not solve the actual problem you need to solve.

And be aware, an algorithm can be 100% secure, while the implementation of the algorithm can make it incredibly vulnerable. When choosing an implementation consider the fact that it can be weak and that it needs to be tested thoroughly.

The series of posts are divided over the following topics.

General approach to Encryption

Applying encryption gets cheaper, but it is still not always free and often not the default. You will have to think about why you want to apply encryption, where you want to apply it and how long the data needs to be secret. If it needs to be secret for 1 day it might actually be smart to choose an algorithm that is more easy on the CPU-cycles. But if it needs to be secret for 10 years you might make a different choice altogether.

There is also the Kerckhoffs's principle. This principle basically says that the security of an encrypted message is not based on the secrecy of the algorithm, but on the secrecy of the key and the key only. This is important. All common algorithms follow this principle and it is key that this is the policy. Only publicly tested, open algorithms that follow the Kerckhoffs's principle should be used. Due to this principle, I left out all encryption algorithms that are patented.

When you look at the variety of encryption and hashing algorithms you honestly do not have that many choices. Yes, you can choose a variety of key-lengths and in some cases a different encryption level and some other settings like block-modes. But I tend to say that creating too much diversity in your own ecosystem just makes encryption more expensive administratively speaking, than when you choose a certain baseline. And don't forget you need to test every option you choose.

The General Policy should be...

  • All chosen algorithms are open and publically known for its security.
  • All chosen algorithms need comply to the Kerckhoff's principle.
  • An algorithm should not be chosen when it is either theoretically or practically compromised/cracked.
  • The chosen algorithm should be sufficient enough to keep the data secret, for as long as it needs to be secret.
  • Always follow the principle of "comply or explain". When it is not technically possible to use a better encryption or hashing, you might downgrade. But do this wisely with proper Risk Management and testing.

An overview on Hashing

Hashing is a way to 'fingerprint' a message. A message can literally be a message, but it can also be, for instance, a file. This fingerprint is a string of characters and numbers. Example: 77c5b98cd533621c15d996723999d19d6c09513f54fddd2d1bdb32c08b6307b6 is the fingerprint for The fingerprint is normally called a hash. This hash is unique to, in this case, If I would generate a hash of (mind the capital T here), then it would generate a different hash. You can test it out on the webpage of David Ciamarro (

In other words, with hashing you can check if your message is sent or received intact. It checks the integrity of the data. And that is all that it does. It is not an encryption, and a hash cannot be unhashed. It is always a one-way street. You can never return from the fingerprint back to its original message.

The different algorithms

There are a variety of different hashing-algorithms out in the open. The ones below are the most well-known (excluding niche variants).
According to current standards (dated April 4th, 2016) the situation is as follows.
  • Deemed insecure*:
    • MD2, MD4, MD5, MD6 and SHA-1
  • Deemed secure, but uncommon:
    • BLAKE, BLAKE2, RIPEMD-160, RIPEMD-256, RIPEMD-320 and SHA-3
  • Deemed secure and common:
    • SHA-2
SHA-2 has a variety of configurations. Three configurations are the most relevant concerning the quality of security of the hash. Those are as follow.
  • Block size: at least 512-bit, but preferably 1024-bit or higher
  • Output size: at least 256-bit (SHA-256), but preferably 384-bit (SHA-384) or higher


The phrase salting is commonly used in conjunction with hashing. Although hashing is often used without salting, it is extremely advised to be used when it comes down to storing passwords or pass-phrases. Salting is the process of adding random data to a message you want to hash (in this case, the password). Salting makes it allot tougher to use crack tools to either guess or crack hashes, because it appends unpredictable data to a hash before it is stored in a database or in a file.

The best practices to use with salting is the fact that every salt is unique, randomized and that it is not being reused. And the salt itself should not be too short. A good method to follow here is that when the output size of a hash is 256-bit, which is 32 bytes, you need a salt of 32 bytes. And the last bit is not to double hashing or use multiple hashes. Proper salting with an up to date algorithm is secure enough.

For allot of details about salting and hashing passwords, please check this blog-post Secure Salted Password Hashing, by Defuse Security.

The Hashing Policy should be...

  • Hashing algorithm: SHA-2.
    • Block size: at least 512-bit, but preferably 1024-bit or higher.
    • Output size: at least 256-bit, but preferably 512-bit or higher.
    • Security: at least 128-bit, but preferably 256-bit or higher.
  • Salt a message before hashing when used to store passwords / passphrases.
    • Every salt is unique, randomized and not reused anywhere else.
    • Every salt is as long as the output size in bytes of a hash of the message.
  • Only use one hashing technique for one message.


That is about it when talking about the General Policy and Hashing Policy. In the next posts I will talk about Encryption and a couple of common implementations of Encryption. 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