Bill Buchanan - The 100 Basic Rules of Cryptography (and Secure Programming‪)‬ ASecuritySite Podcast

Kerckhoff’s principle defines that “a Cryptographic system should be designed to be secure, even if all its details, except for the key, are publicly known”, but there aren’t too many other rules defined. So here are my 100 Basic Rules of Cryptography (and Secure Programming). First, my Top 10:
Cryptography is both an art and a science. Cryptography needs to be both theoretical and practical — one without the other leaves gaps. The maths is not actually that difficult — it is just the way that researchers talk about it that is a problem. Know your knowledge gaps — and plug them. Your university education is unlikely to have properly set you up for the serious world of cryptography. Crypto is cryptography and not cryptocurrency. Few methods are perfect — know the limits of any method you use. Don’t cook your own crypto! How many times do you have to say this to yourself? Security-by-obfuscation never works that well. Confidentiality, Integrity and Assurance are different things and require different methods. Don’t merge them all together into one thing. And the rest:
Digital certificates and PKI (Public Key Infrastructure) are two of the least understood areas of cybersecurity — don’t expect many people to understand them. For public key encryption, you encrypt with Alice’s public key, and she decrypts with her private key. For public key signatures, you sign a hash of the message with your private key, and Alice proves your public key. Your baseline hack is always brute force. Know how many dollars it would cost the NSA to crack something. Machine code can reveal your secrets. A hack of one key should not lead to the loss of all the previous keys. A key should only exist for the time it was meant to exist for. Use session keys wherever possible, and watch out for long-term keys. Your role is typically to protect the user and not reveal things to the NSA. Listen to experts, and be a teacher to others. Be open with your knowledge, and don’t pretend you know something that you don’t. Try and understand the basics of the maths involved — otherwise, you are trusting others. Understand entropy, and know how to calculate it and prove it with experiments. Run entropy calculations before pushing related code to production. Don’t use a method unless it has been peer-reviewed and published. Understand the strengths and weaknesses of your methods. No method is perfect —but at least know what problems it might cause and try and mitigate against these. Know why you have chosen X over Y, and be able to defend the reason to others. The maths may be sound, but human is typically the main weakness. Everything will work fine until it doesn’t. Test for out-of-band conditions as much for good conditions. Zero is not your friend in cryptography, so always know what it will do to your system. Don’t just catch exceptions; action them. Do not allow to progress unless everything checks out okay. Log good and bad. Catch good things, along with bad things. Monitor your security logs for exceptions and bad operations. Remove debugging code from your production version. Keep up to date with the latest research. Beware of backdoors in methods and code. Side channels are smart ways to reveal the 1s and 0s, and every bit discovered reduces the security level by two and makes it so much less expensive to crack. Every bit drops the price tag for a crack by a half. The core security of your system is likely to depend on the generation of random oracles (seed values). Make sure they are generated so they do not repeat within a given time and cannot be brute forced by the NSA. If you can use real randomisation and not pseudo-randomness. If you generate pseudo-randomness, take the randomness from several sources. Continually review your code, and get external experts to review it. Don’t push your code in production until you have tested it — fully! Check the code in the libraries you use, and perhaps, don’t use