Cryptography Introduction Cheatsheet – part 5 – Best Practices

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).
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

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.

Others

  • 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;

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.