[fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)

[Gordan Bobic]

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