Cryptography and D

[Nick Sabalausky via Digitalmars-d]

On 7/5/2014 8:23 AM, Kagamin wrote:
>
> There was a study, showing that most security vulnerabilities are caused
> by client code rather than cryptographic library code.

Interesting. Link?

> 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.

FWIW, DAuth (pending a possible name change, to prevent confusion with 
the completely unrelated OAuth) maintains a list of non-recommended algos:

   https://github.com/Abscissa/DAuth/blob/master/src/dauth/core.d#L109

And, by default, it will error out (at compile-time whenever possible) 
if the application code attempts to use any such algorithm:

   https://github.com/Abscissa/DAuth/blob/master/src/dauth/core.d#L169

Getting around the error requires acknowledging your intent via 
-version=DAuth_AllowWeakSecurity

Also, DAuth encourages passwords to be stored in a special structure:

   https://github.com/Abscissa/DAuth/blob/master/src/dauth/core.d#L311

which attempts to zero-out the password from memory as early as it can 
(and encourages the user to populate it via char[] not string to avoid 
having an un-wipable immutable plain-text copy in memory. See 
'toPassword' vs 'dupPassword'). I'm certain the implementation can be 
improved. And I'd kinda like to make it scoped if I can, instead of 
refcounted. But it's something.

Obviously there are natural limits to these measures, so it can't 
*guarantee* anything, only help guide the application developer. And it 
doesn't/can't address all possible issues. But it's at least something.