Understand (before you start writing code) the basic security properties that you want to deliver through use of cryptography. This is usually where most implementers fall over (including the big commercial products).
To give a couple of specific (but non-exhaustive) examples, generally framed in terms of password managers:
- A password manager should protect the identity of the sites the user has saved, the content of the username and password field, and any associated notes. (That's fairly straightforward, most people are likely to agree on this). But what about integrity? Should you use an authenticated cipher mode like GCM? What will you do if the authentication tag fails verification?
- The password should be encrypted such that if a password is re-used across websites, it is not discernable from the ciphertext that this is the case. (Fewer people will think about this, but some will... Using AES in ECB mode isn't enough to prevent this! Lastpass appear to have done this in the early days).
- The key used to encrypt each ciphertext should probably be unique, to reduce any potential impacts of weaknesses in ciphers or cipher modes. Each cipher should use a unique per-instance instantiation as well (i.e. IV, GCM tag, etc.) How do you store and derive these passwords though? That will take you into key derivation functions, and password-based ones, like scrypt/bcrypt/argon2. These can derive a crypto key from a user password. You can then use that key as input to a KDF (with a per-entry salt) to derive the actual AES key used for each entry.
- If you're designing a wire protocol, what properties do you seek? Replay resistance? How do you prevent session resumption type attacks? (don't design a new wire protocol, use something robust like modern TLS!)
98+% of the time, at least in my experience, people who mess up crypto don't understand what goal they are seeking to achieve by using the cryptography, and haven't threat modelled it. Usually this is because regular devs are being asked by "BigCorp" to add "AES 256 crypto" to meet a client tick-box requirement. I would say if you understand how people are likely to seek to break/compromise what you are building, you can then start to design a solution. Expect to read 10x more articles than you expect, and before you start writing any code though.
And don't focus too much on getting an expert to review the code only - you ideally want to get some input reviewing the concept, architecture, understanding of the threat model, and the security properties you want to deliver. I've blown huge holes in crypto systems before, as people did things "nearly" right, but didn't understand the wider application, so were exposing/leaking the key elsewhere etc.
To give a couple of specific (but non-exhaustive) examples, generally framed in terms of password managers:
- A password manager should protect the identity of the sites the user has saved, the content of the username and password field, and any associated notes. (That's fairly straightforward, most people are likely to agree on this). But what about integrity? Should you use an authenticated cipher mode like GCM? What will you do if the authentication tag fails verification?
- The password should be encrypted such that if a password is re-used across websites, it is not discernable from the ciphertext that this is the case. (Fewer people will think about this, but some will... Using AES in ECB mode isn't enough to prevent this! Lastpass appear to have done this in the early days).
- The key used to encrypt each ciphertext should probably be unique, to reduce any potential impacts of weaknesses in ciphers or cipher modes. Each cipher should use a unique per-instance instantiation as well (i.e. IV, GCM tag, etc.) How do you store and derive these passwords though? That will take you into key derivation functions, and password-based ones, like scrypt/bcrypt/argon2. These can derive a crypto key from a user password. You can then use that key as input to a KDF (with a per-entry salt) to derive the actual AES key used for each entry.
- If you're designing a wire protocol, what properties do you seek? Replay resistance? How do you prevent session resumption type attacks? (don't design a new wire protocol, use something robust like modern TLS!)
98+% of the time, at least in my experience, people who mess up crypto don't understand what goal they are seeking to achieve by using the cryptography, and haven't threat modelled it. Usually this is because regular devs are being asked by "BigCorp" to add "AES 256 crypto" to meet a client tick-box requirement. I would say if you understand how people are likely to seek to break/compromise what you are building, you can then start to design a solution. Expect to read 10x more articles than you expect, and before you start writing any code though.
And don't focus too much on getting an expert to review the code only - you ideally want to get some input reviewing the concept, architecture, understanding of the threat model, and the security properties you want to deliver. I've blown huge holes in crypto systems before, as people did things "nearly" right, but didn't understand the wider application, so were exposing/leaking the key elsewhere etc.