On Tue, May 24, 2011 at 11:20, Gordan Bobic <gordan(a)bobich.net> wrote:
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.
Gordan
_______________________________________________
arm mailing list
arm(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren