Cryptography and D

[Kagamin via Digitalmars-d]

On Sunday, 29 June 2014 at 19:25:30 UTC, Chris Cain wrote:
> Of course, following all of those suggestions isn't trivial to 
> begin with. Technically, you're right, but because what you 
> said isn't easy to follow to begin with, it doesn't support the 
> argument of "you can implement a crypto algorithm."

Following those guidelines don't require knowledge in 
cryptography. And D automtically provides good level of pedantism 
of bound checking, so this part should be easier.

> Basically, if you have data you must have secured (the reason 
> why you'd use a crypto algorithm to begin with), you must go 
> beyond a sane level of pedantry. The only acceptable insane 
> level of pedantry I know of is only possible with people that 
> have doctorates in cryptography. :)
>
> Plus, add what Xinok said. That's showing the level of pedantry 
> we're talking about with crypto where you have to cover things 
> like timing attacks and power analysis (or, admit that your 
> crypto library isn't suitable for covering those attacks).
>
> That's not to say you shouldn't ever do it, but you really need 
> to truly understand what it is you're doing when you implement 
> any crypto. Even using crypto requires a certain (often 
> ignored) level of knowledge or you introduce issues.

There was a study, showing that most security vulnerabilities are 
caused by client code rather than cryptographic library code. For 
example, how would you prevent client code from generating weak 
encryption keys or from using weak algorithm for hash comparison, 
or how would you force it to do what's not required to get the 
code compiled? How would you do that with the quality of library 
code? Even if you can do that, it's still not a cryptographic 
task, but a general programming task, the standard only hints you 
that those things are necessary.