"Cryptography Engineering" by Niels Ferguson, Bruce Schneier, Tadayoshi Kohno

• Security is only as strong as the weakest link, and the mathematics of cryptography is almost never the weakest link.
• There is nobody in the world who knows everything about cryptography.
• So here is your first lesson in cryptography: keep a critical mind. Don’t blindly trust anything, even if it is in print.
• Cryptography by itself is fairly useless. it has to be part of a much larger system.
• Cryptography is only truly useful if the rest of the system is also sufficiently secure against the attackers.
• A security system is only as strong as its weakest link.
• To improve the security of a system, we must improve the weakest link.
• Attack trees provide valuable insight as to possible lines of attack. Trying to secure a system without first doing such an analysis very often leads to useless work.
• To work in this field, you have to become devious yourself. You have to think like a malicious attacker to find weaknesses in your own work.
• Paranoia is very useful in this work.
• Professional paranoia is an essential tool of the trade. With any new system you encounter, the first thing you think of is how you can break it. The sooner you find a weak spot, the sooner you learn more about the new system.
• Any work is fair game. If somebody proposes something, it is an automatic invitation to attack it.
• Also, when you attack a system, always be sure to criticize the system, not the designers.
• Every system can be attacked. There is no such thing as perfect security.
• Cryptography is fiendishly difficult. Even seasoned experts design systems that are broken a few years later.
• There is no known way of testing whether a system is secure.
• Key management and key storage is crucial to any cryptographic system, but most computer have no secure place to store a key.
• If it fails, back off and become more conservative.
• Good security is always a mixture of prevention, detection,and response.
• Complexity is the worst enemy of security, and it almost always comes in the form of features or options.
• The best way to have confidence in building something secure is to keep it simple.
• Complexity is a measure of how many things interact at any one point.
• A good encryption function makes it impossible to find the plaintext m from the ciphertext c without knowing the key.
• An important rule is Kerckhoffs’ principle: the security of the encryption scheme must depend only on the secrecy of the key K, and not on the secrecy of the algorithm.
• Don’t trust secret algorithms.
• Authentication is almost always combined with a numbering scheme to number the messages sequentially.
• Encrypting a message doesn’t stop manipulation o f its contents, and authenticating a message doesn’t keep the message secret.
• One of the classical mistakes in cryptography is to think that encrypting a message also stops it from changing it. It doesn’t.
• The problem of distributing and managing keys is one of the really difficult parts of cryptography, for which we have only partial solutions.
• All public-key encryption schemes depend heavily on mathematics.
• Public-key cryptography makes the problem of distributing keys a lot simpler.
• Public-key encryption is much less efficient, by several orders of magnitude. Using it for everything is simple too expensive.
• In practical systems that use public-key cryptography, you almost always see a mixture of public-key and secret-key algorithms. The public-key algorithms are used to establish a secret key, which in turn is used to encrypt the actual data.
• Digital signatures are the public-key equivalent of message authentication codes.
• Trying to decrypt a message if you only know the ciphertext is called a ciphertext-only attack. This is the most difficult type of attack, because you have the least amount of information.
• A known-plaintext attack is one in which you know both the plaintext and the ciphertext. The most obvious goal is to find the decryption key.
• A distinguishing attack is any nontrivial method that detects a difference between the ideal encryption scheme and the actual one.
• It [the birthday attack] is an attack that depends on the fact that duplicate values, also called collision, appear much faster than you would expect.
• In general, if an element can take on N different values, then you can expect the first collision after choosing about sqrt(N) random elements.
• With enough effort, any practical cryptographic system can be attacked successfully. The real question is how much work it takes to break a system.
• Any system designed today really needs at least a 128-bit security level.
• The more complex a system, the more likely it has security problems. Indeed, we like to say that complexity is the worst enemy of security.
• The only way to get a secure system is to build a very robust system from the ground up. This requires a simple system.
• Don't ever trust a secret block cipher (or any other secret cryptographic primitive).
• It is sometimes useful to look at a block cipher as a very big key-dependent table.
• A secure block cipher is one for which no attack exists.
• An attack on a block cipher is a non-generic method of distinguishing the block cipher from an ideal block cipher.
• A distinguisher is an algorithm that is given a black-box function that computer either the block cipher X or an ideal block cipher. The distinguisher’s task is to figure out whether the black-box function implements the block cipher X or the ideal cipher.
• If the block cipher has an explicit security level of n bits, then a successful distinguisher should be more efficient than an exhaustive search on n-bit values.
• An ideal block cipher implements an independently chosen random even permutation for each of the key values.
• The cryptographic community doesn’t trust a cipher until it has been reviewed thoroughly by other experts.
• You are much better off using one of the well-known ciphers that already has been reviewed for you.
• Virtually all block ciphers consists of several repetitions of a weak block cipher, known as a round. Several of these weak rounds in sequence make a strong block cipher.
• Most attacks on block ciphers begin by attacking version with a reduced number of rounds.
• We do not recommend using either DES or 3DES in new designs.
• An S-box is basically just a lookup table that is publicly known.
• The basic structure of DES is called the Feistel construction.
• Without good diffusions, a small change in the plaintext would lead to a small change in the ciphertext, which would be very easy to detect.
• The Advanced Encryption Standard (AES) is the U.S. government standard created to replace DES.
• If you are developing a system or standardizing a protocol, we recommend building in some flexibility or extensibility in case you need to replace AES with another block cipher in the future.
• AES is still what we recommend. It is fast. All known attacks are theoretical, not practical. Even though AES is now broken academically, these breaks do not imply a significant security degradation of real systems in practice.
• For almost all applications, a 128-bit security level is enough. However, to achieve 128 bits of security, we suggest keys longer than 128 bits.
• For a security level of n bits, every cryptographic value should be at least 2n bits long.
• For 128-bit security, we really want to use a block cipher with a block size of 256 bits.
• Use 256 bit keys!
• If you want to encrypt something that isn’t exactly one block long, you have to use a block cipher mode.
• You should always combine encryption with authentication.
• The most important rule is that padding must be reversible.
• We suggest one of two simple padding scheme:
• Append a single byte with value 128, and then as many zero bytes ass required to make the overall length a multiple of b.
• Determine the number of padding bytes required, n, and pad the plaintext by appending n bytes, each with value n.
• The code that removes the padding should also check that the padding was correctly applies.
• Do not ever use ECB for anything!
• The cipher block chaining (CBC) modes is one of the most widely used block cipher modes.
• You should not use a fixed IV, as that introduces the ECB problem for the first block of each message.
• The standard solution is to choose a random IV and to send it as a first block before the rest of the encrypted message.
• The principle disadvantage of a random IV is that the ciphertext is one block longer than the plaintext.
• nonce: The term is a contraction of “number used once.” The critical property of a nonce is that it it unique. You should never use the same nonce twice with the same key.
• The nonce does not have to b secret, but it can be used only once.
• The IV necessary for CBC encryption is generated by encrypting the nonce.
• Stream ciphers are extremely useful, and do their work very well. They just require a bit of care in their use. Abuse of a stream cipher, mostly in the form of reusing a nonce, can very easily lead to an insecure system.
• One advantage of OFB so that decryption is exactly the same operation as encryption, which saves on implementation effort. A second advantage is that you don’t need any padding.
• If there’s ever a doubt, you should use a mode like random IV CBC mode.
• If you can guarantee that the nonce will be unique, then CTR mode is very easy to use.
• There are really only two modes we would consider using: CBC and CTR.
• We now recommend CBC with random IV.
• Always keep in mind that an encryption mode only provides confidentiality.
• All block cipher modes leak some information.
• There is no easy way of achieving a 128-bit security level with a block cipher whose block size is 128 bits.
• A hash function is a function that takes as input an arbitrarily long string of bits (or bytes) and produces a fixed-size result.
• Hash functions are sometimes called message digest functions, and the hash result is also known as the digest, or the fingerprint.
• Hash functions can be used in cryptographic pseudorandom number generators to generate several keys form a single shared secret.
• They have a one-way property that isolates different parts of a system, ensuring that even if an attacker learns one value, she doesn’t learn the others.
• There are several requirements for a hash function. The simplest one is that it must be a one-way function.The collision-resistance requirement merely states that, although collisions exist, they cannot be found.
• The ideal hash function behaves like a random mapping from all possible input values to the set of all possible output values.
• An attack on a hash function is a non-generic method of distinguishing the hash function from an ideal hash function.
• There are very few good hash functions out there. At this moment, you are pretty much stuck with the existing SHA family.
• It is safe to say that MD5 is very weak and should no longer be used.
• It is no longer safe to trust SHA-1.
• Let h be an iterative hash function. The hash function h-double is defined by h-doublet(M) := h(h(m) || m).
• We recommend using one of the newer SHA hash function family members--SHA-224, SHA-256, SHA-384, or SHA-512.
• In the long term, we will very likely recommend the winner of the SHA-3 competition.
• A message authentication code, or MAC, is a construction that detects tampering with messages.
• A MAC is a function that takes two arguments, a fixed-size key K and an arbitrarily sized message m, and produces a fixed-size MAC value.
• An ideal MAC function is a random mapping from all possible input to n-bit outputs.
• An attack on a MAC is a non-generic method of distinguishing the MAC from an ideal MAC function.
• The idea behind CBC-MAC is to encrypt the message m using CBC mode and then throw away all but the last block of the ciphertext.
• In general, one should never use the same key for both encryption and authentication.
• We don’t advocate the use of CBC-MAC directly, because it is difficult to use correctly. One alternative we recommend is CMAC.
• We like the HMAC construction. It is neat, efficient, and easy to implement. We would only use it with a 256-bit hash function such as SHA-256.
• We would choose HMAC-SHA-256: the HMAC construction using SHA-256 as a hash function.
• The Horton Principal: Authenticate what is meant, not what is said.
• Whenever you do authentication, always think carefully about what other information should be included in the authentication.
• To implement a secure channel, we need a shared secret.
• In most situations, modifying data is a devastating attack, and does more damage the merely reading it.
• Message numbers are vital for various reasons. They provide a source for IVs for the encryption algorithm; they allow Bob to reject replayed messages without the necessity of keeping a large database; they tell BOb which messages were lost in transit; and they ensure that Bob receives the messages in their correct order.
• The secure channel is one of the most useful applications of cryptography, and it is used in almost all cryptographic systems.
• It is very easy to screw up the security at the implementation level.
• Real-life systems include many components that were never designed for security, and that makes it impossible to achieve the level of security that we really need.
• Attacks on the cryptography are especially damaging because they can be invisible. If the attacker succeeds in breaking your cryptography, you are unlikely to notice.
• Another important reason to do the cryptography right is that it is very difficult to switch cryptographic systems once they’ve been implemented.
• Secure software has a requirement: a lack of functionality. No matter what the attacker does, she cannot do X.
• Standard implementation techniques are entirely inadequate to create secure code.
• A basic rule of writing security software: wipe any information as soon as you no longer need it. The longer you keep it, the higher the chance that someone will be able to access it.
• Something that surprises many people is that simply overwriting data in memory does not delete the data.
• Complexity is the main enemy of security. Therefore, any security design should strive for simplicity.
• Most users are not informed enough about security to be able to select the correct security options. The best solution is to have no options and make the system secure by default. If you absolutely to, provide a single option: secure or insecure.
• Only optimize those parts of your program that you can measure as having a significant effect on the performance.
• Assertions are a good tool to help improve the quality of your code.
• When implementing cryptographic code, adopt an attitude of professional paranoia. Each module distrusts the other modules, and always checks parameter validity, enforces calling sequence restrictions, and re uses unsafe operations.
• Assertion failures should always lead to an abort of the program with ample documentation of which assertion failed, and for what reason.
• The general rule is: anytime you can make a meaningful check on the internal consistency of the system, you should add an assertion. An error caught by an assertion will not lead to a security breach.
• Generating wrong answers is probably the worst thing a program can do. It is much better to at least inform the user that a programming error has occurred, so he does not trust the erroneous results of the program.
• Our recommendation is to leave all your error checking on.
• Avoid any programming language that allows buffer overflows. Specifically: don’t use C or C++. And don’t ever switch off array bounds checking of whichever language you use instead. It is such a simple rule, and will probably solve half of all your security bugs.
• Generating good randomness is a vital part of many cryptographic operations. Generating good randomness is also very challenging.
• The measure for randomness is called entropy.
• Entropy does not measure how many bits are in a value, but how uncertain you are about the value.
• Pseudorandom data is not really random at all. It is generated from a seed by a deterministic algorithm. If you know the seed, you can predict the pseudorandom data.
• We only use real random data for a single thing: to seed a PRNG. This construction resolves some of the problems of using real random data.
• Once the PRNG is seeded, random data is always available.
• Fortuna can be used a s drop in replacement for most PRNG library functions.
• The Sieve of Eratosthenes is still the best algorithm for generating small primes.
• For public-key cryptography, the primes we want to generate are 2000-4000 bits long. The basic method of generating a prime that large is surprisingly simple: take a random number and check whether it is prime.
• A proper program should never hang, independent of its inputs, so we limit the number of tries and generate a failure if we exceed this number.
• If you are lazy and don’t want to generate the small primes, you can cheat a bit. Instead of trying all the primes, you can try 2 and all odd numbers 3,5,7,...,999, in that order. This sequence contains all the primes below 1000, but also contains a lot of useless composite numbers.
• The one thing the DIffie-Hellmen does not protect against is the so-called man-in-the-middle attack.
• There is a big difference between key sizes for symmetric primitives and key sizes for public-key primitives like DH. Never, ever fall into the trap of comparing a symmetric key size to the size of a public key that can be thousand of bits. Public-key sizes are always much larger than symmetric-key sizes.
• A signature failure should be taken like any other failure in a cryptographic protocol: as a clear signal that you are under active attack. Don’t send any replies unless you absolutely have to, and destroy all the material you are working on.
• When working on protocols, you must assume that you are dealing with the enemy.
• Trust is the ultimate basis for all dealing that we have with other people. If you don’t trust anybody with anything at all, why bother interacting with them?
• Don’t ever trust research that supports the company that paid for it.
• A good way to encode fields is to use Tag-Length-Value or TLV encoding.
• Errors need very careful handling, as they are a potential avenues of attack.
• Protocols quickly get too complicated to keep in your head, and that is dangerous Once you don't understand it all, it is almost inevitable that a weakness slips in.
• Real-world systems always have her large protocol specifications.
• Our advice: be very careful with protocol complexity.
• Most block ciphers and hash functions are comparatively easy to test.
• Any decent test set for a symmetric primitive will exercise all the possible flows of control in the implementation.
• Don’t implement your own large integer routines. Get an existing library.
• The basic idea behind whooping is to verify a computation module a randomly chosen small prime.
• Every RSA signature computation should verify the results by checking the signature just produced. There is no excuse not to do this.
• There are several ways to protect yourself against timing attacks. The most obvious one is to ensure that every computation takes a fixed amount of time.
• The danger of large key servers is that all the keys are in a single place.
• Simplicity is one of our main design criteria, so we prefer fast expiration to a CRL database.
• For small systems, the extra complexity of a PKI is in general not warranted.
• Cryptography cannot help with the initial distribution of the root certificate, because there are no keys that can be used to provide the authentication.
• The longer you keep a key, and the more you use it, the higher the change an attacker might manage to get your key. If you want to limit the chance of the attacker knowing your key, you have to limit the lifetime of the key.
• Humans are notoriously bad at memorizing passwords.
• Use a salt. This is simply a random number that is stored alongside the data that was encrypted with the password. If you can, use a 256-bit salt.
• The next step is to stretch the password. Stretching is essentially a very long computation.
• We suggest using a 256-bit salt.
• Secure tokens are currently one of the best and most practical methods of storing secret keys.
• As soon as a secret is no longer needed, its storage location should be wiped to avoid any further compromise.
• Magnetic media are very hard to wipe.
• In practice, repeatedly overwriting a secret with random data is probably the best option.
• A security system is only as strong as its weakest link; to be secure, everything must be right. And that is something you simply can’t learn from reading books.