-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Aloha!
Niels Möller wrote:
Which variants are recommended, or in real use? 20 and 12, just like for salsa20?
DJB does not state anything about recommended number of rounds but 8 i bare minimum. Both Adam Langley and we use 20 rounds:
http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-00
http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-00
I assume that 12 is today the lower limit. But being able to use something in between 12 and 20, or more than 20 is good (imgho)
Adding chacha benchmarking in examples/nettle-benchmark should be easy.
Ok, I'll look at that.
I'm used to patches on the mailing list (I still feel a bit like a git newbie. I could also pull changes from a repository of yours, but I'd prefer a mailed patch unless I'm confident I want to integrate the work directly with no changes). An ideal patch set for chacha would include
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 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. ;-)
[list of deliverables]
Preferably arranged so that independent changes (C implementation, docs, assembly implementation) can be applied one at a time. This is a wish list, to make integration quick and easy, but you don't have to get everything in order for the contribution to be useful.
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've only had a quick look at the actual code now, but my first impression is that it looks pretty good. I think I'd prefer to not have the number of rounds in the context, though, and instead have separate functions for different variants, possibly calling a common function taking the number of rounds as argument.
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.
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.
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.
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. But the user can always call the base function and change the number of rounds for each message (if needed). Sounds ok?
- -- Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim@secworks.se ========================================================================