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.
