I can think of two others that are lesser known but probably more common among devs trying to do crypto right.<p>The first is modulo bias. It's common to see someone take a secure random int and try to fit it into a constrained range. There is no easy way to do this without shifting off entire bits!!! Modulo operations produce biased results unless your constrained range is a power of two. This is a consequence of binary number representation and you can't work around it without a lot of gymnastics or using simple discard to throw away all the generated numbers outside your desired range.<p>If you absolutely must have a constrained and securely random int the easiest way to do it is bitshift down to the closest power of two then discard any numbers outside the range. This is fairly quick, never discards more than half your numbers, and doesn't mess with the randomness of the distribution.<p>Another one, the difference between a secure hash like SHA and HMAC is extremely dangerous. Possibly the most common and dangerous cryptographic mistake by anyone that isn't just incompetent.<p>I see the majority of developers using hashes based on Merkle Damgard construction such as MD5 and SHA1/2 . When these hashes are being used to verify integrity of anything user supplied they can be trivially attacked using length extension. These attacks are real and one even happened to Flickr a couple years back.
<a href="http://netifera.com/research/flickr_api_signature_forgery.pdf" rel="nofollow">http://netifera.com/research/flickr_api_signature_forgery.pd...</a>
<a href="https://en.m.wikipedia.org/wiki/Merkle–Damgård_construction" rel="nofollow">https://en.m.wikipedia.org/wiki/Merkle–Damgård_construction</a> .<p>Look at the terrifying list of "other vulnerable APIS", some big names in there. When using these types of hashes YOU MUST USE HMAC. It's slower but the bare algorithm is unsafe in many (most?) real world applications and I have no idea why language designers make them available so everyone can screw up their crypto.<p>A third one is more of a fun crypto hack, but on some platforms you really don't trust the RNG. You can make up for this somewhat by getting a single secure random input from a person then generating more numbers by encrypting the same string to itself over and over.<p>It used to be uncool to generate random numbers using AES because of the "entropy pool" concept. Eventually everyone realized this was nonsense and now RNG's are.much faster :)