
Top Developer Crypto Mistakes - r4um
https://littlemaninmyhead.wordpress.com/2017/04/22/top-10-developer-crypto-mistakes/
======
slackingoff2017
I can think of two others that are lesser known but probably more common among
devs trying to do crypto right.

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.

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.

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.

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.
[http://netifera.com/research/flickr_api_signature_forgery.pd...](http://netifera.com/research/flickr_api_signature_forgery.pdf)
[https://en.m.wikipedia.org/wiki/Merkle–Damgård_construction](https://en.m.wikipedia.org/wiki/Merkle–Damgård_construction)
.

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.

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.

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

