Cryptographic Operations: Best Practices To Make Your System Secure

This article outlines cryptographic operations and best practices you should follow to make your applications or systems secure.

Cryptography has been around as long as the written history of mankind. This is because of human nature - we always have something to hide. The full story is perfectly explained in Wikipedia. The point is, this is a never-ending competition between people inventing ciphers and people breaking ciphers. Computers intensified the competition. Computers make ciphers incredibly strong, on the other hand, computers help to break the ciphers. It is like a sword vs. a shield. It is very important to use a proper shield.

The modern era: asymmetric cryptography

Before the 1970s, cryptography was only used to keep secrets. This all changed when asymmetric cryptography was invented. Deeply theoretical ideas were implemented - all possible thanks to computers. These include:

• Hash functions: The hash function (or one-way function) is a mathematical function transforms a variable-length integer value  to a fixed length integer value. The reverse computation is impossible - this is a key point here.

• Asymmetric encryption: Asymmetric cryptographic systems use one key to encrypt data and different key to decrypt.

The topics above are explained well in any book about cryptography. My point is, that these two functions (asymmetric cryptography and hashes) gave us digital signatures, key exchange and many other things we can’t do very well with traditional symmetric cryptosystems. Yes, you can digitally sign data using a symmetric cipher via an ugly over-complicated method, but it’s very hard to implement.

Why we must be up-to-date

Computers continue to become more and more powerful. Now we are in the early stages of quantum computers (Maybe we will have super-string computers soon). Consequently, ciphers we use today will be too weak tomorrow. During my practice MD5, SHA-1 were cracked, RSA-512 became too weak. However, many systems and applications still use MD5!!

Indeed, there are additional obstacles. I am talking about the theory. We are progressing in the cryptographic theory. Most of the algorithms we use are an implementation of the Feistel network - Twofish, DES, even Russian GOST. This network is explored very well - and all ciphers mentioned seem to be reliable enough (if key size, round count are chosen properly).

It could be argued that AES (or Rijndael) is still a dark horse. On one hand, it was developed by highly experienced professionals and well-tested by thousands of researchers around the Globe.  On the other hand, the Titanic was also developed by professionals :) Joking aside, at one point in time, somebody (maybe a student or enthusiast) may find some internal AES symmetry, making AES very weak or easily decrypted. No guarantee. Generally speaking, only ONE cipher can be guaranteed - the Vernam cipher.  

The situation with asymmetric ciphers is that the theory is not well developed, due to deep mathematical reasons. Asymmetric cryptography offers the term “computational complexity”. This means we can't decrypt the cipher because we don't currently have an efficient attack on the computationally-complex problem and/ or we don’t have a computer powerful enough yet. This is a reason why armies don't like or ignore asymmetric ciphers.

The lack of proof produces lot of speculations. Americans may suspect that Russians know a FAST factorization algorithm enabling them to break American asymmetric encryption and may disadvice to use them. Russians may think (I guarantee) in similar terms.

Normal users have no choice but need to trust the experts.  As users we should always ask them questions:

1. What key size is strong enough today?
2. Is there known theoretical weakness in this cipher?
3. Was this cipher broken yesterday?
4. Do I use the correct procedure for retention, removal, renewal, destruction, etc. of the key?
5. How big is my exposed attack surface?

Do we have such professionals we could (and may) ask? Yes. We do. It's NIST. They accumulate best practices, knowledge and experience in our industry.

The essence of NIST recommendations

NIST provide you a some very useful recommendations about:

1. Approved algorithms
2. Reasonable key sizes to provide strong encryption
3. Recommended cryptoperiod
4. Key management, recommended procedures
5. Correct approach to build crypto-protocols

All those matters are important and will help you very much to avoid stupid mistakes and, more important, unauthorized information disclosure. Cryptography is a deep water - many hidden rocks are inside. Any cryptographic protocol exposes some vulnerability. Please read the following NIST topics:

1. Session keys. Each encrypted block, is sent over an open channel, “eats” your key. Even when you use correct encryption method - CBC, for instance. So change a session key every n blocks, every n seconds, every sessions as described by NIST.
2. Encryption modes : ECB, CBC etc. Read about initialization vector attacks
3. Understand the oracle attack and unexpected information disclosure

Hopefully, most cryptographic libraries follow NIST recommendations and will not permit you do really bad things. However, still keep the recommendation in mind.

Make it better!

Do not follow NIST recommendations blindly - think for yourself. Obviously, NIST does not know about your specific use-cases and sensitivities. Remember, NIST gives you general recommendations, helping you avoid stupid mistakes or reinventing the wheel. Follow them, but not too formally and blindly. Cryptography is your closest friend, so use it properly, according the logic and knowledge. Think!

1. Rethink recommendations about crypto-periods. A crypto-period depends  on the usage frequency of a key. One digitally signed document per month requires one cryptoperiod; 5.6 billion requires a much shorter period!
2. Carefully think about your Key Encryption Keys (KEKs). Every time you use KEK, you give a hint to a crypto-analytic. Change you KEKs appropriately.
3. Think twice - do you provide too much meta-information in your protocol?
4. Combine cryptographic computations with other security mechanisms. If you encrypt the file, use ACLs to make an additional layer of protection. Learn your OS security mechanism carefully!
5. Use dedicated cryptographic hardware whenever possible - dedicated hardware is basically much harder to hack and also produces better quality keys to start with. Put your system users’ private keys into smart cards, server-based keys - in an HSM.
6. Use special software tools - code encryptors to establish security zones.
7. Use “security by obscurity” very carefully. It could help you in some circumstances, but not to trust it solely.
8. Think like a hacker, discuss all sides of your security with colleagues. Brainstorm it.
9. Zone (segment) your application[s] (system) - find a fully trusted zone, a zone with partial trust,  and untrusted one. Imagine it, draw it and discuss with colleagues. Put your keys (especially - anchor keys!) in the fully trusted zone!

In summary, NIST recommendations are good in typical cases. The real world is a bit wider, however. So - think for yourself! 

References and Further Reading

• Selected articles on Key Management (2012-16), by Ashiq JA, Dawn M. Turner, Guillaume Forget, James H. Reinholm, Matt Landrock, Peter Landrock, Steve Marshall, Torben Pedersen, Peter Smirnoff and more 
• NIST Special Publication 800-57 Part 1 Revision 4 Recommendation for Key Management Part 1: General (2016), by Elaine Barker, Computer Security Division Information Technology Laboratory, National Institute of Standards and Technology
• Trusted Computer System Evaluation Criteria ("The Orange Book") (1985), The U.S. Defence Department
• Predictions 2017: Customer-Obsessed Enterprises Launch Cloud’s Second Decade (November 2016)
• “Cybersecurity Incidents What Happened.” (2016), the United States Office of Personnel Management.

Image: "Hash Tag", courtesy of Michael Coghlan, (CC BY-SA 2.0)