Early std.crypto

Brad Anderson eco at gnuk.net
Sat Nov 26 16:19:23 PST 2011


On Fri, Nov 25, 2011 at 10:31 PM, bcs <bcs at example.com> wrote:

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

How about putting a disclaimer on the module warning the code hasn't been
through a rigorous security audit and point them at well established C
libraries if they need that sort of assurance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111126/4c3b7425/attachment.html>


More information about the Digitalmars-d mailing list