On 03/21/2011 03:04 PM, Niels Möller wrote:

I don't know how the build system for the perl bindings is setup, but using something like autoconf should make it easier if you really want to support multiple nettle versions, with or without public key support.

that's an interesting suggestion -- i'm afraid i don't know enough about integrating autoconf with perlxs to know how to go down that path without a more research, but i'll consider it for the future. It would only allow backward-compatibility, though -- not forward-compatibility. That is: if you built Crypt::Nettle against libnettle version X, and then upgraded to libnettle version Y, you'd have to also re-build Crypt::Nettle.

That's not a horrible tradeoff, i guess.

But some other parts of the nettle interfaces have not been as stable between releases, so it doesn't solve the problem completely.

yes, that's true -- i'm proposing this just for the ciphers and hashes at the moment.

One may want to think about fancy hardware accelerators (currently not supported at all), which would require some runtime check on what's available.

that's an interesting part i hadn't considered. I'm not certain how to represent such a change, but i like the idea that one could discover available/supported hardware dynamically somehow. Would supporting that use case suggest a different API?

I'm not sure this is as useful. The modes have different properties and generally don't work well as substitutes for each other. And at least, the list is expected to be expanded less frequently than the list of hashes or block ciphers.

OK. Maybe this is a good target for the autoconf approach you mentioned above.

Some comments on the implementation:

...

+const struct nettle_armor *nettle_armors[] = {

• &nettle_base64,
• &nettle_base16,
• NULL

+};

The typing should be something like

const struct nettle_armor * const nettle_armors[]

to say that both the list itself and the pointed to structures are const.

Yes, you are right, thanks!

Also, I think there should be one compilation unit and object file per list, so that it's, for example, possible to statically link with the list of all hash algorithms without also dragging in all ciphers.

Is there any reason to use this approach for statically-linked tools? Maybe for UI or hardware discoverability, i guess. It certainly wouldn't help in terms of software discoverability or forward/backward compatibility in a statically-linked library.

Do you want me to submit a modified patch with these changes?

--dkg

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

On 03/21/2011 04:32 PM, Daniel Kahn Gillmor wrote:

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

Attached is a patch that breaks out separate compilation units, const-ifies the arrays, and adjusts the docs and the test suite.

I did not see nettle_armor in the docs at all, so i didn't add any docs about nettle_armors[]. Maybe that whole section needs to be written?

Any further comments?

--dkg

nisse@lysator.liu.se (Niels Möller) writes:

Thanks. I'm going to commit this.

Checked in now.

I also wrote a program tools/nettle-hash to take advantage of the new interface. Comments appreciated.

Should output be more compatible with md5sum, sha1sum et al? But I think I like to also include information on the algorithm used.

Should it have a -c (check) mode as well?

Regards, /Niels

Daniel Kahn Gillmor dkg@fifthhorseman.net writes:

Any further comments?

The following (in nettle.texinfo) looks a bit strange.

+@deftypevrx {Constant Struct * Constant} {struct nettle_hash *} nettle_hashes[]

+@deftypevrx {Constant Struct * const} {struct nettle_cipher *} nettle_ciphers[]

I'm no texinfo guru, but I think the first {...} is supposed to be just a category (Function, Macro, Variable, etc), and the second {...} the type. I thik

@deftypevrx {Constant Struct} {struct nettle_hash **} nettle_hashes

would be more correct (unless we want a new categories "Algorithm List" which I think is a bit overkill), but I haven't yet checked the generated output.

Regards, /Niels