Joachim Strömbergson <joac...@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 -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
