Crypto algorithms

Crypto Algorithms are the basic building blocks of encryption. Above them are protocols (“how do we glue algorithms together to achieve our goal ?”). And above the protocols are libraries offering an easy programming interface to use a protocol.

In many cases the user of the library still has to pick the algorithm to slot into the protocol. A basic knowledge of the algorithms will prevent many bugs.

I will skip the mathematics and try to build simple “Good vs Bad” tables. If you want to dig deeper, please read the books in the links.

A good crypto algorithm is created and tested in challenges. It will get a good peer review by other crypto experts. When mathematics improves (and computers get faster as well) the estimated time to crack it will shrink. Moore’s law predicts a increase of processing power by factor 2 every 18 months. GPUs, ASICs and Clouds (lots of cheap computers from Amazon Cloud, for example) can also bring down the attack time.

Normally experts will warn months or even years before a realistic attack on an algorithm is possible. That’s the time to move on to use a better algorithm.

Be prepared to swap the algorithm used in your products and services

If you rely on a crypto book on your desk, check out the date it was published. During the last years new attacks have been invented and some algorithms and protocols did not age well. If your decisions still are based on a book from 1995 they will be wrong - even if the book was great at that time.

Be aware: This chapter is an extreme simplification. If crypto security is an essential part of your project dig deeper and use the further reading section.

Hash functions

Hash functions are one way functions that generate a value of a fixed size from any length of input. One input always generates the same Hash. On the other hand: One Hash can be the same for different inputs.

For security reasons it must be impossible:

• To revert the process and calculate the input from the Hash
• To generate two inputs with the same Hash

A CRC is not a Crypto Hash function. It is good for validating bit flips in data. But not to prevent or detect human attacks. Still some people use it that way…

shattered.io on breaking SHA-1

SHA256 and SHA512 are SHA-2 hashes. Where the number indicates the bit length.

SHA-3 aka Keccak: Is developed as fallback for SHA-2. SHA-2 is still good. But if something should happen to it, there is SHA-3 with is based on a totally different internal principle.

BLAKE2 was in the SHA-3 contest. Its main feature is speed. There are different variants optimized for different architectures. The core ones are:

• BLAKE2b: for 64 bit platforms
• BLAKE2s: For 8 to 32 bit platforms

If you need speed, give it a chance.

HMAC or MAC

MAC allows Integrity and Authentication. Simplified: It is a Hash with a shared key involved. That way the parties can authenticate the origin.

Password hash functions

While other hash functions are efficient, for password hashes we want inefficient hash functions. On a normal server it does not matter that much if 1 or 500 milliseconds are wasted on calculating the Hash. But the attacker wanting to break a database dump with hundreds of thousands Hashes gets into lots of trouble thanks to the in-efficient hash.

Links:

• Argon
• BCrypt
• PBKDF2

Stream Ciphers

Stream ciphers are used especially in telecommunication to encrypt a data stream (mobile phone voice channel).

Block Ciphers

Block Ciphers are the work horse to encrypt large data. Besides selecting the Algorithm and the key length it is also important to use it in the proper mode. There will be an own table for that.

Algorithms

3DES is rated mediocre because AES offers a better key-length to protection ratio. You should be using that.

Modes

Block ciphers are encrypting the data block-by-block. The mode defines if and how the encryption of one block influences the encryption of the other blocks.

If possible use AEAD.

Some of those modes need more data in addition to the password to initialize the encryption: a number named IV (initialisation vector) or nonce (number used only once). This number can be public. But it has an important requirement: Do not recycle it ! This number must be used once only. For the next data you encrypt use a different one. With that requirement: A counter would do the job pretty well.

Authenticated Encryption

Combining a MAC and an encryption results in Authenticated Encryption.

The most common AE technology is AES Galois Counter Mode (AES-GCM)

One important differentiation is if to do MAC first or encryption. It seems during the years - as experience grew - the shift was towards “Encrypt-then-MAC” as best practice.

MAC and cipher must use distinct keys. But there are foot guns and alternatives to this whole AE complex.

If you go down that road, please check out “further reading” and at least 2 more books. Implementing this is lots of work (months-for experts). Invest your time into smartening up first.

Or use libraries implementing this technology ready-to-use (which I would do).

Asymmetric Ciphers

RSA: you should use 2048-4096 bit key length (security levels of 90 to 128 bits)

Encryption: Cipher text should be padded. RSA-OAEP does this (Optimal Asymmetric Encryption Padding)

For signatures with RSA use RSA-PSS(Probabilistic Signature Scheme)

Key exchange

To do a key agreement/key exchange the state of the art is DH: Diffie-Hellman protocol. It can be used in different flavours.

• Anonymous DH is breakable by man-in-the-middle attacks
• Authenticated Diffie–Hellman: breakable by replay attacks
• MQV is best but complex

Most often used is Authenticated DH

Elliptic Curve Cryptography (ECC)

Elliptic curve based cryptography is an upgrade on many crypto protocols. It offers more security for less key length. And thanks to the smaller keys it is often faster.

If possible replace your RSA and DH with ECC.

EC crypto depends on one special parameter: the curve it runs on. The curve has to be special. You can not make up your own. Instead use one of the standard curves:

• NIST curves
• Curve25519 (which is very common)

Key length

Depending on your computing power, lifetime of your product and adversary this may vary. But sane best-practice key lengths are:

• Asymmetric: >= 3248 bit
• Elliptic Curve to replace classical asymmetric crypto: >= 256 bit
• Symmetric: >= 128 bit

A source for a more specific evaluation of your required key length is here.

Best practice

• Never encrypt without authentication: The cryptographic doom principle

Further reading

Serious Cryptography by Jean-Philippe Aumasson

Serious Cryptography is Mathematics paired with some hands-on. It contains lots of common mistakes being made when using those algorithms and protocols. It should be on your desk when building something with cryptography.

The Mozilla TLS guide

Mozilla TLS guide is a collection of TLS server settings for different situations. A good cheat sheet ranking the current quality of algorithms in a pragmatic (“don’t break the web”) environment.

BetterCrypto.org

BetterCrypto is a project aimed at helping admins. They offer a free manual with lots of specific crypto settings for different applications. It also contains basic algorithm overviews.