[dm-crypt] [PATCH] support OpenSSL's libcrypto and make libgcrypt optional

Jussi.Laako at nokia.com Jussi.Laako at nokia.com
Fri Jul 30 16:21:17 CEST 2010


Hi,

On 29.7.2010 15:01, "ext Milan Broz" <mbroz at redhat.com> wrote:

> But I do not want to use runtime plugin architecture but compile time
> decision only.

Sounds reasonable.

> So for you patch:
> - seems you are reverting some configure options which are not needed,
> I think it is enough to have someting like --with-crypto=[gcrypt,openssl,nss]
> or so.

I can try to look into this later, though I'm not an autotool wizard... :)

> - using #ifdef is not ideal, mainly in crypto code - it is easy to break
> algorithm when using wrong defines. It need properly define crypto backend
> callbacks and switch only its implementations. And include tests
> (I have already PBKDF2 testvectors test, that should be used for all
> backends.)

Sounds good, I can update the OpenSSL specific code once the needed backend
changes are there.

> - I think openssl backend function should not duplicate all the code
> for every algorithm

True, there's no really nice way to have it with this backend interface
using the low-level OpenSSL crypto API. I rewrote the backend (attached) to
use a bit higher level EVP interface which made it a lot cleaner. The
initialization part is needed when the EVP_get_digestbyname() is in use.
When not using the name lookups but the code below, it shouldn't need
separate initialization.

Also needed once extra change to backends.c in order to call the
initialization. (incremental patch attached)

> - there is still hardcoded gcrypt logic on some places (including api-test),
> so it still links to gcrypt, all regression tests must run with all supported
> backends. Probably some basic list of must-have algorithms should be defined
> for crypto backends. (e.g. I am using whirlpool hash for testing, not all
> crypto backend support it currently.)

I'll look into this in September, unless Alexander has time to take a look
at that part earlier.

Quite common older versions of OpenSSL don't have whirlpool, but 1.x series
has it.

> Are you ok with supporting this in compile time only (so there is always
> only one backend in compiled binaries - depends on distro preference)?

Yes, that's OK, since we just like to avoid forcefully bringing in duplicate
functionality through dependencies, when possible.


Best regards,

    - Jussi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: meego-cryptsetup-backends.patch
Type: application/octet-stream
Size: 590 bytes
Desc: meego-cryptsetup-backends.patch
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20100730/7c084f0f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssl.c
Type: application/octet-stream
Size: 2888 bytes
Desc: openssl.c
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20100730/7c084f0f/attachment-0001.obj>


More information about the dm-crypt mailing list