Early std.crypto

[Piotr Szturmaj]

Brad Roberts wrote:
> On 10/24/2011 5:10 PM, Piotr Szturmaj wrote:
>> https://github.com/pszturmaj/phobos/tree/master/std/crypto
>>
>> This is some early work on std.crypto proposal. Currently only MD5, HMAC and all SHA family functions (excluding SHA0
>> which is very old, broken and no longer in use). I plan to add other crypto primitives later.
>>
>> I know about one SHA1 pull request optimized for SSSE3. I think native code must be there to support other non x86 CPUs
>> and SIMD optimization may be added at any time later.
>>
>> Any opinions are welcome. Especially if such design is good or bad, and what needs to be changed.
>>
>> Thanks :)
>
> A key element to a lot of crypto code is speed.  I really don't think we want to re-invent all the optimizations on all
> the platforms.  To that end, I really suggest that we stick to wrapping existing implementations, like openssl.  While I
> hate the openssl apis, I do respect the continual effort that various companies invest in optimizing the code.

You are of course right about speed but there are some reasons for 
having our own code _if_ we want std.crypto:

1. Phobos independence
2. Non D friendly API of openssl
3. No need to link with openssl to compute a simple hash.
4. Licensing

We also have some options for speed improvement, while retaining our API

1. Wrap openssl _on demand_, this is transparent to the user, API 
doesn't change
2. Many (if not all) openssl asm code may be obtained using CRYPTOGAMS 
license (BSD). But reading http://www.openssl.org/~appro/cryptogams/ 
suggests that author might be willing to license it under Boost.
3. Adapt Crypto++ asm code which is public domain (x86/64 only)

The 1st one should be easy, and user would have choice between openssl 
wrapped within std.crypto or direct access to etc.c.openssl.