Early std.crypto

[bcs]

On 11/22/2011 08:16 AM, Piotr Szturmaj wrote:
> bcs wrote:

>> How many people in the D community have the experience and know-how to
>> review the security of an implementation? If there are less than 2 or 3
>> people who can do that, can we afford to include native kernels? We
>> can't have just one and if we have only two and one leaves for some
>> reason the code becomes un-maintainable for lack of a reviewer. *I*
>> wouldn't be comfortable with less than about 4-5.
>
> I know Regan Heath who wrote some crypto code for Tango. Also, I suspect
> that D _will_ gain more (crypto) contributors, especially after joining
> GCC.

"Wrote some crypto code" is a rather weak recommendation. Depending on 
how you interpret it, that would recommend *me*. A better recommendation 
would be "Mr Y gets paid by security company X to do crypto analysis" or 
"Mrs Z has published several well review papers on vulnerabilities in 
this kind of code".

> Minimum number of contributors/reviewers requirement in open-source
> project is at least unfortunate in my opinion. Nevertheless, I respect
> your thoughts. But imagine what could happen if Walter waited for
> contributors instead of starting D project on his own?
>
> Please realize that we do not implement every possible crypto algorithm
> at once. We need to start with something like hashing, then add
> encryption and other cryptographic primitives.

I have no problem with that comment. My concern revolves around the 
point that the implementation of cryptographic primitives has security 
implications. I'm worried that we don't have the resources to 
demonstrate that our implementation is at least as good as the currently 
available implementation. I'd rather Phobos not include a given 
primitive than contain one of unknown quality. What I'd like to see is 
that the crypto package quickly contain interfaces for all the 
primitives we can find pre-vetted Boost licensed implementations for. At 
that point I would have no issue with as methodical and meticulous 
effort to divest ourselves of external dependencies as we can get access 
to the expertises needed to vet our own implementations (to the same 
level as the code they are replacing).

Yes, I'm intentionally being paranoid here but this is security and 
paranoia is part of the job description darn-it.