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