It was supposed to be the way forward regarding all this. Last I
checked, it was only for applications, not libraries, though.
On Tue, May 24, 2011 at 13:32, Stephen John Smoogen <smooge(a)gmail.com> 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.
> arm mailing list
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
arm mailing list