Early std.crypto

bcs bcs at example.com
Sun Nov 27 13:29:12 PST 2011

On 11/27/2011 12:15 PM, Piotr Szturmaj wrote:
> Jude Young wrote:
>> On Sun 27 Nov 2011 10:27:58 AM CST, bcs wrote:
>>> On 11/26/2011 04:19 PM, Brad Anderson wrote:
>>>> 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.
>>> What does that gain over implementing the first itteration in terms of
>>> well established C libraries and then replacing that with native
>>> implementations as the code goes been through a rigorous security audit?
>>> Or how about do both as API compatible implementations? That would
>>> work for people who need the proven security and people who can't
>>> afford external dependencies as well as allow them to be swapped out
>>> for each other with minimal effort once the native code is proven.
>> I do like this idea.
>> swap implementations by simply swapping import and linking?
>> nice.
> This was my goal... to write native implementation along with OpenSSL
> wrapper and add 'useOpenSSL' version identifier. Would that satisfy
> everyone?

Yes, though I'd prefer to see them distinct and non-mutually exclusive. 
For one things, someone may well consider the native implementation of 
one primitive vetted before they consider another to be. Both results 
could be had by the suitable application of aliases.

More information about the Digitalmars-d mailing list