And because cryptographic errors cannot be tested in any simple way, developers need to focus on correct implementation in the first place. What does this mean?
1. Don't invent your own algorithms
We have AES, RSA, DSA, ECDSA and so on. If you are making a real world application that is going to protect some sensitive data, don't even think about making your own encryption algorithm. Doing that is fine if you're just playing with encryption for fun or are a seasoned cryptographic researcher who eats algebra for breakfast. In production, you can just as well go juggling grenades.
2. Assume the attacker knows what algorithms you use
Relying on the attacker not knowing which cryptographic primitives you are using is about as safe as jumping off a cliff. Security is ensured by using secret keys and correct algorithms. If you make the mistake of violating this principle and an attacker discovers how you app works (every kid can use disassembly of Python, Java, .NET nowadays), what are you going to do about it? Try to change the implementation in 10 hours and ship a critical update? Building the security of your system on trying to hide implementation details ensures nothing but headache.
3. Use crypto primitives in exactly the way they are designed to be used
To stay secure (and enjoy the feeling of extra protection, dryness and safety!), you need to use cryptographic primitives in exactly the same way they were designed to be used and in no other way. There is a number of tools in the cryptographer's toolbox and each of them has a different purpose. Let's list some of them:
- symmetric encryption (AES, Twofish, ...)
purpose: Hide data from an attacker using a key known to both parties.
incorrect use: trying to use encryption to prove the author of a message - asymmetric encryption (RSA, ...)
purpose: hiding data from an attacker using an asymmetric key - hash functions (SHA)
purpose: get a fixed length data digest from a long message that doesn't allow getting any info about the original message
incorrect use: trying to ensure that an attacker hasn't changed the message along the way
incorrect use: checking if the entered encryption password is correct - password based key derivation functions (PBKDF2, scrypt...)
purpose: generating a key for encryption algorithm from a password
incorrect use: not using PBKDF at all and putting the password directly into the encryption algorithm - digital signatures (DSA, ECDSA, RSA, ...)
purpose: ensure that the holder of private key really authored the message
incorrect use: out of ideas how to abuse this - message authentication codes (MAC)
purpose: making sure that the message has not been changed on the way when both parties share a secret key
incorrect use: not using it when data integrity is important - key agreement protocol (Diffie-Helman, ...)
purpose: You have two parties and they know each other's public key. This allows you to generate a shared secret using the public keys.
4. Handle parameters correctly
For example, encryption algorithms usually work in block modes and it's up to you to choose the block operation mode according to your needs. If you use ECB, I'm sorry and you can say "bye bye" to your privacy (unless your data is smaller than 128 bits).
Block modes also need a random IV and that data must be transmitted together with the cryptotext. It's a hassle, but if you come up with a "solution" such as generating the IV from the password, you're violating the rule number 3 (do what you are told to do and don't make your own solutions) and defeating the entire purpose of the IV (which is to ensure that you always generate different cryptotexts even when reusing parts of data or password).
More complicated encryption schemes (such as ECIES) need some other data to be also transmitted with the message. Again, you have to implement this exactly according to the spec and refrain from custom inventions such as reusing the ephemeral curve, otherwise you are compromising your own data security.
A very useful article is Cryptographic right answers.
More complicated encryption schemes (such as ECIES) need some other data to be also transmitted with the message. Again, you have to implement this exactly according to the spec and refrain from custom inventions such as reusing the ephemeral curve, otherwise you are compromising your own data security.
Conclusion
This article is merely a short summary, it doesn't provide the why for the rules. Usually, the reason is that incorrect use either enables some unexpected way for the attacker to get your data, to tamper with them or to calculate statistical information about them, which is also more serious than most people would expect. You can always find the answers are out there on the internet in specifications of the individual primitives.A very useful article is Cryptographic right answers.