Joachim Strömbergson joachim@secworks.se writes:
I haven't worked that much with Gitorios and esp not the one at Lysator. But Git and es Github supports good mechanism for an owner/integrator such as you to receive merge requests from downstream clones, test them as branches and then decided if to include them as a whole or cherry pick.
I've never really used the web stuff of either gitorious or github. If you put up a repo I can pull from, I'll most likely add it as a remote and fetch from it using the git command line tools.
I've used Gitorious before but really think Github is a much better service. This might be a stupid question but have you considered to move Nettle to Github? It would I assume get more exposure and probably more contributions. If that is what you want. ;-)
As a GNU maintainer, I'd like to avoid depending on things which are proprietary software, or software-as-a-service. But as long as github does plain git, I can fetch changes from github repos if the need arises.
I'll try and get them done for you hopefully this week. A lot of peeking at previous paytches in the maillist archive and stealint/borrowing from other code (salsa20) should help me out. If not I'll post on the list.
I look forward to that. I can't promise I'll be as quick with integration, but hopefully I'll get some hacking time during the Christmas break.
I can agree that the number of rounds is not really something to keep in the context. But I think that the solution of having the number of rounds fixed and having separate functions for the different versions is pretty ugly and inflexible.
That's a judgement, of course. In nettle, I don't think it makes sense to add flexibility for the sole purpose of convenient support for obscure algorithms or settings. If a wider range of rounds gets used in practice, we can reconsider this. With salsa 20, with only two variants (12 or 20 rounds) in use, I don't think separate functions gets too ugly.
I can see the need for applications to easily and dynamically change from 12 to 14 rounds by simply updating a variable, possibly even a loadable value instead of changing the code forcing a recompile.
That's not my experience. The typical crypto application has some configuration or protocol handshake to select between aes128-ctr, aes256-ctr, salsa20, salsa20r12, etc. For each choice, it needs some logic to allocate the right context struct and call the right functions (struct nettle_cipher is an example of a minimalistic framework to collect that info).
Then, from the application's point of view, salsa20r12 is as different from salsa20 as it is from aes128-ctr, none can be be substituted for the other except via the algorithm selection procedures, and it really doesn't matter which of the different algorithms are unified below that algorithm-selection framework.
And the particular change from 12 to 14 might add significant complexity to an optimized implementations with 4-way unrolling, so flexibility isn't always as cheap as it looks.
The salsa20 implementation does not come with different function calls for 128 and 256 bit keys. Instead the length is given as a parameter. I don't see the number of rounds being that much different.
The difference is that the key size matters *only* for the set_key function, there's no need to store it in the context struct.
And I think functions for specific would make a lot of sense also for salsa20. In Nettle, passing a key size as argument to the set_key functions used to be the norm, with a few exceptions for single key size algorithms like DES. But I'm now reconsidering that design. Today, I think a set_key function with a key_size parameter is appropriate only for algorithms which support more or less arbitrary keysizes. When only two or three discrete key sizes are specified, I prefer to view them as distict algorithms. In particular, I prefer that view if the keysetup really uses different logic for the different key sizes.
I suggest that the chacha_crypt function is accepting number of rounds as a parameter. You can then if you want add specific named functions that wrap this function.
That's a perfectly valid implementation choice to me. A similar function for sala20 has been discussed earlier. We might need to think a bit about naming. And the wrapper functions are necessary, for nettle_cipher if nothing else.
Regards, /Niels