On 05/24/2011 06:32 PM, Stephen John Smoogen wrote:
On Tue, May 24, 2011 at 11:20, Gordan Bobicgordan@bobich.net wrote:
On 05/24/2011 06:11 PM, Andrew Haley wrote:
On 05/23/2011 04:12 PM, Gordan Bobic wrote:
omalleys@msu.edu wrote:
My question, is how hard is this to implement the hardware support non-openssl programs.
Not particularly hard if you're writing your own crypto implementation anyway, but there's a lot to be said for just linking against OpenSSL. It's probably safer to link against the library that has a lot of eyes on it than it is to implement your own.
OpenAFS could use this as it can use a lot of DES encryption, but it uses its own DES implementation. It also happens to be the only one I can think of off the top of my head that uses its own implementation. It would be nice to have.
gpg seems to use its own AES implementation that's slower than SSL's. It would certainly be nice to fix that to use acceleration.
Sounds like it might be a good idea to post a feature request to the upstream bugzilla. Have you checked if there is a build option to make it link against OpenSSL instead of using the bundled crypto stack?
There may be a license incompatibility. OpenSSL has an advertising clause in it I believe which makes it incompatible with various GPL unless an exception is given.
I didn't think that matters on dynamic linking. Does it? And we are specifically talking about dynamic linking to get the features of the system OpenSSL install.
Gordan