On 05/24/2011 06:32 PM, Stephen John Smoogen wrote:
On Tue, May 24, 2011 at 11:20, Gordan Bobic<gordan(a)bobich.net>
> On 05/24/2011 06:11 PM, Andrew Haley wrote:
>> On 05/23/2011 04:12 PM, Gordan Bobic wrote:
>>> omalleys(a)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.