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.
- Part 1 - General Policy and Hashing Algorithms
- Part 2 - Asymmetric and Symmetric Encryption Algorithms
- Part 3 - Encryption Implementations
- Part 4 - Summary: The Encryption and Hashing Security Policy
General approach to Encryption
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.
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
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 algorithmsThere are a variety of different hashing-algorithms out in the open. The ones below are the most well-known (excluding niche variants).
- BLAKE: BLAKE, BLAKE2
- Message Digest: MD2, MD4, MD5 and MD6
- RACE Integrity Primitives Evaluation Message Digest: RIPEMD-160, RIPEMD-256, RIPEMD-320
- Secure Hashing Algorithm: SHA-1, SHA-2, SHA-3
- 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:
- 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
SaltingThe 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.
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.