This is an aggregation of links to recommendations and standards for best encryption practices.
I wrote this back in 2013, but not much has changed for encryption level standards – these are still best sources I can find. So I’m reprinting an old post in the hopes of propagating better information.
This question is getting asked a lot, and the answers you see out in the public sphere of the internet range from pathetically underwhelming to just plain wrong in some cases. So this is my attempt to point people in the right direction. When you do see people who know what they are talking about discussing security the talk can turn towards holy wars, philosophical rabbit holes, or just become so overburdened with acronyms that a layman has to give up. So I’m going to point you to some concise and comprehensive web documents to help solve the problem.
Disclaimer: I’m not an authority, nor am I speaking for my employer, or any other group; this is entirely my own humble opinion.
You must use a combination of security protocols, practices, and standards to truly secure your data and network into the next decade. The brute force hacking ability available to individuals has been greatly extended and enhanced the past few years. By strapping together a high-powered computer and some high-powered video cards hackers can have the power of one of yester year’s supercomputers in their hands without spending the equivalent of a small nation’s budget to get there. Everything, including the methods in the links I’m going send you to, is theoretically hackable given enough computing horsepower and time. Your task is to make the time and horsepower curve too steep for hackers anytime in the immediate future and to persistently upgrade as these methods and standards evolve.
The first stop is Cisco and their next generation encryption white paper. Pay attention to the tables in the document first – upgrading to the recommended Next Generation encryption levels is best, but where circumstance, budget, or hardware capacities prevent that you should go to the “acceptable” levels, and if even that’s not possible, then at least try to meet the minimums in appendix A at the bottom and then add some controls to protect or mitigate your weakly encrypted data. Pay the most attention to tables one and two, which are pretty self-explanatory, and please read the caveats in the text, the heavier overhead encryption methods can cause hardware and software processing overload if you don’t engineer to right capacity. Also note that there’s an NSA paper linked if you need to see what’s needed for Government encryption security.
Next stop is the National Institute of Standards & Technology PDF http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf – this document tells you what our best standards body thinks. At this link you will find many NIST PDFs on most security processes, recommendations, and standards that you might care about including Key Generation & Handling.
The next stop is W3C – since so much of what we do is web centric, it’s very important to make sure Developers are securing data locally, through web encryption standards, and for cross site vulnerabilities. If you are following modern web standards then you’ll be using a bit of XML to share data & you will find sub links for encrypting XML as well as other protocols, and since it’s important to follow standards to prevent hacking, you should use the W3C validation tools against your pages regularly.
All of this is for naught however if you don’t layer your security – encrypting is just one part of protecting data. You must also consider physical layers, process deterrents, and prevention of social engineering attacks. When all is said and done remember that you must still be able to work – don’t make yourself so secure that you can’t.