Part 5 – Overview Best Practices
This is the fifth part in a list of cheatsheets based on the book Network Security: Private Communications in a Public World (2nd Edition).
This post provides an overview of some best practices. The first part, Cryptography Introduction Cheatsheet – part 1, was about cryptography, the second part, Cryptography Introduction Cheatsheet – part 2, about authentication, the third part Cryptography Introduction Cheatsheet – part 3, about standards and the fourth part Cryptography Introduction Cheatsheet – part 4 – Electronic Mail, about electronic mail.
Perfect Forward Security
PFS – Perfect Forward Security is a protocol property that prevents someone who records an encrypted conversation from being able to later decrypt the conversation, even if they gotten hold of both sides cryptographic secrets.
It can be done with a Diffie-Hellman exchange (as in IKE) and have both sides forget the D-H information after the conversation.
The other way of doing it is as in SSL/TLS where one side, Bob, generates a public/private key and the other side, Alice, sends a random number encrypted with the public key.
Change keys periodically
The more examples of ciphertext you see, the more likely it becomes someone will be able to break the encryption and find the key. So when any key has been used on a certain amount of data you should change keys, key rollover.
Multiplexing flows over a single SA
Different conversations should not be multiplexed to use the same security association (SA). Traffic belonging to different service classes should also not be using the same SA. Ideally different SAs should also use different algorithms.
Use different keys in the two directions
This avoids reflection attacks.
Use different secret keys
Use different keys for
- encryption and integrity protection;
- different purposes;
- signing and encryption.
Have both sides contribute to the master key and Don’t let one side determine the key
Attackers have to learn both side’s private key and if either side has a good random number, the result will be a good random number.
Key expansion is the technique of using a small number of random bits as a seed and from it deriving lots of bits of keys.
- Hash in a constant when hashing a password;
- Randomly chosen IVs;
- Use of nonces in protocols;
- Don’t let encrypted data begin with a constant or a predictable value;
- Compress data before encrypting it. Compression has to happen before encryption because compression depends on the data being somewhat predictable;
- Don’t do encryption only, also do integrity protection;
- Avoid weak keys;
- Put checksums at the end of data;
- Design a protocol with forward compatibility;