On Tue, May 24, 2011 at 6:11 PM, Andrew Haley <aph(a)redhat.com> 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.
It would be better to use nss as it has the option of all the various
fips certifications which would be useful for gpg.
Alternatively I would think it would be better to use the HW crytpo
user interface directly so you get HW acceleration if it avail or
fallback if its not. I'd personally prefer not to use openssl for gpg
as its not the most secure beast.