making algorithms in nettle dynamically enumerable

[Daniel Kahn Gillmor]

On 03/21/2011 04:07 PM, Niels Möller wrote:
> But I think the API you suggested is good enough for now.

ok.

> The general principle is that independent functionality should be in
> separate object files. I don't think this case is an exception. To be a
> little more concrete, say you want a tool that can compute a hash sum
> using any algorithm supported by nettle, and you then want that tool on
> some constrained system with statically linked binaries, or included in
> a statically linked busybox executable.

Gotcha, this is a useful way to think about things.  Thanks for your
explanation.

> That would be nice. Documentation would also be appreciated (it should
> probably mention why des is not on the list, but I don't think it needs
> to be terribly many words). Test cases are perhaps not essential for
> this, but maybe you can think of some relevant test?

i'll work on a revised patch with docs and a test if i can figure out a
test as well.

> It may also be good to review the naming. Until now, the name attribute
> in nettle_cipher and similar structs has been intended to be displayed
> for informational purposes only. With your interface, users will be
> invited to use it as an identifier to look up an algorithm. How do you
> intend to use that name in the perl bindings?

The perl bindings already expose an enumeration + lookup interface, but
i've implemented it myself outside of nettle.  I'll be happy to keep the
existing perl API but drop the Crypt::Nettle implementation of it in
favor of one in the main library, though.

fwiw, i have no objections to the current naming scheme.  I'll probably
do a case-insensitive match against the exported names.

Your earlier suggestion that the user should be able to say "aes" and
then we would select an algorithm based on the supplied keysize suggests
a particular simple naming convention, where the keysize is always a
strict suffix to the algorithm name.

That is, a library might use a function by comparing the requested
algorithm name as a strict prefix with the size of the keylength.

I suppose that selection function could be part of libnettle as well,
instead of making each binding report it.  something like:

const nettle_cipher*
nettle_select_cipher(const char* algoname, int keylength = 0);

This would not remove the need for the other API, though, since it
doesn't provide algorithm enumeration.

I can try to include such an implementation in the revised patch if
y'all think it would be useful.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
Url : http://lists.lysator.liu.se/pipermail/nettle-bugs/attachments/20110321/dcc4dc64/attachment.pgp