Show notes
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 them if there are no open-source repositories. If you can, open source your libraries. Watch out for version updates on your code, and try and lock a given (known) version to your code. Encrypt anything that looks like PII (Personally Identifiable Information) at rest and over the air. Remember that running memory can reveal keys and cryptographic artefacts, so know the risk. Learn a new method every day, and don't get stuck with the same old crypto! Quantum computers will happen one day and will disrupt our life, so start thinking about the impact they might have. Revealing your private keys is like giving someone the keys to your castle, so know where they are and restrict access to them. Only give access to private keys to those you most trust to use them properly. Air your development environment from your production environment, and don't let private keys propagate. The best systems use zero trust. No rights to anything unless they can be proven. You will — at times — need to revoke your public keys. Be aware of the processes involved and of the embarrassment it will cause. Educate the board on the importance of good crypto! Encourage your team to undertake academic study, and get them to reserve a few hours a week for independent study of new methods. Read classic research papers, and don't dismiss methods because they are not currently used. Collaborate with an academic team which has complementary skills to your own team. If you lack theoretical knowledge in your team, get external experts to come in for a chat. Once a private key is destroyed, any data encrypted with it is also likely to be destroyed. Limit the copies of a secret key. If you can, keep your keys in an HSM (Hardware Security Module). Cryptography in the Cloud pushes you to the limits and will often enhance the methods you use. Back up those secret keys, but make sure they are well-wrapped before putting them in a place that others can access. Learn about the garbage collector and how your program deals with data when running. Leave the coding of the maths in papers to experts. Don't trust auditors to prove the security of your system. Generally, auditors are likely to have little understanding of the methods you will use — get experts to review your methods. Beware of Denial of Service (DoS) on your code — such as continual exception handling. Most systems boil down to one single thing that defines the overall security — know what this is. If you are interested in the X method, go and contact the person that created it — you will often be surprised how open many researchers are in sharing their ideas. Watch those CVE updates like a hawk — it can be a race between you and your adversary. On Cloud-based systems, log everything about your keys. In the Cloud, only allow keys to be used for the purpose they should be used for, and don't use them generally. Limit access to keys for services and roles. Reduce the impact of a stolen or lost secret key. Never encrypt large-scale data infrastructures with the same secret key — try to use envelope encryption. Passwords are dead — replace with cryptographic signing methods. Your enemy can be within. Watch out for key stealing and deletion. Tell your incident response team about the difference between losing encrypted data and non-encrypted data. Scan your network for secret keys placed in locations where they should not be stored. Know what the acronyms mean and not just what they stand for. Know why we use message authentication codes (MACs). If you need to generate an encryption key from a password or secret, pick a good KDF (Key Derivation Function), and know the cost to crack it. Rainbow tables aren't much of a threat anymore, so make use your use a good salt value. Everything below 72 bits of entropy is likely to be crackable by the NSA — unless a slow method is used for the processing with the key. Nonce/salt values should start at 96 bits. Never use anything less. RC4 has been cracked … get over it. Stream ciphers can often be broken — make sure you never reuse your salt value. DES and 3DES are mainly uncracked, but DES only uses a 56-bit key, so never use it Compared with ECC, RSA requires a good deal more processing and has larger key sizes, but it is still great. ECDSA suffers from nonce reuse attacks. For digital signatures, you should delete the nonce value after the signature has been created, but for symmetric key and hashing, you need to store it. In ECC, the public key is a point on the elliptic curve. For secp256k1, we have a 256-bit private key and a 512-bit (x,y) point for the public key. A "04" in the public key is an uncompressed public key, and "02" and "03" are compressed versions with only the x-co-ordinate and whether the y coordinate is odd or even. Consider writing papers — it is a great way to develop your writing and abstraction skills. Don't sit back with the status quo — try to continually improve privacy and security. Have a risk register and maintain it. Don't be shy, and don't hide things. Have someone to check your code — on a regular basis. Remember Moore's Law … computing power is increasing every year, so know that something that is safe now might not be in 10 years. Know how long something needs to be kept secure and secure for that age (and a lot more). And there you go … 100 rules of cryptography