Hi,
I probably won't convince you anymore, so feel free to ignore this :) Anyway, I just wanted to say that
#define CHACHA128_KEY_SIZE 16 #define CHACHA256_KEY_SIZE 32 [...] void chacha128_set_key(struct chacha_ctx *ctx, const uint8_t *key); void chacha256_set_key(struct chacha_ctx *ctx, const uint8_t *key);
looks horribly wrong to me. There is no "Chacha128" nor "Chacha256"; given that the standard naming scheme interprets a number after "Chacha" as number of rounds... well, this is just wrong. Forcing the AES naming onto other stuff is just not a good idea imho.
My preference, if you want to have a fixed length in the name, is still "chacha_set_key128" and similar. Not sure about "chacha_128_set_key", "chacha20_128_set_key", ...
As a side note: the paper for Chacha only mentions the 256-bit key variant, although the reference implementation also provides the 128-bit variant... So I'm not sure whether the 128-bit variant was actually intended being used at all.
regards, Stefan
Stefan Bühler nettle-bugs@stbuehler.de writes:
My preference, if you want to have a fixed length in the name, is still "chacha_set_key128" and similar. Not sure about "chacha_128_set_key", "chacha20_128_set_key", ...
Thanks for the feedback.
As a side note: the paper for Chacha only mentions the 256-bit key variant,
Interesting, I hadn't noticed that.
although the reference implementation also provides the 128-bit variant...
But the reference code really is very close to salsa20, it even uses "salsa20" in the name of one if the internal functions.
So I'm not sure whether the 128-bit variant was actually intended being used at all.
Does anyone else know of use or interest in 128-bit chacha keys? It would definitely make things a bit simpler if we can omit support for 128-bit keys. (And if we skip it now, we could of course reintroduce it later if it turns out to be needed).
Regards, /Niels
"NM" == Niels Möller nisse@lysator.liu.se writes:
NM> Does anyone else know of use or interest in 128-bit chacha keys?
Given DJB's paper¹ on parallel hardware cracking, which strongly suggests against using 128 bit symmetric if one is concerned about well funded adversaries, I doubt there are any.
1] IINM, I'm thinking of http://cr.yp.to/snuffle/bruteforce-20050425.pdf
-JimC -- James Cloos cloos@jhcloos.com OpenPGP: 1024D/ED7DAEA6
nisse@lysator.liu.se (Niels Möller) writes:
Does anyone else know of use or interest in 128-bit chacha keys? It would definitely make things a bit simpler if we can omit support for 128-bit keys. (And if we skip it now, we could of course reintroduce it later if it turns out to be needed).
For now, I've deleted the support for 128-bit chacha keys. And replaced the "chacha256_" prefixes by "chacha_".
Not sure what to do about 96-bit nonces. I think I'll leave that for now, and maybe introduce a chacha_set_xnonce later in case both nonce-sizes needs to be supported.
Regards, /Niels
On Tue, Mar 4, 2014 at 2:40 PM, Niels Möller nisse@lysator.liu.se wrote:
Does anyone else know of use or interest in 128-bit chacha keys? It would definitely make things a bit simpler if we can omit support for 128-bit keys. (And if we skip it now, we could of course reintroduce it later if it turns out to be needed).
For now, I've deleted the support for 128-bit chacha keys. And replaced the "chacha256_" prefixes by "chacha_". Not sure what to do about 96-bit nonces. I think I'll leave that for now, and maybe introduce a chacha_set_xnonce later in case both nonce-sizes needs to be supported.
It has not been approved yet, but the latest TLS proposal for chacha is with 96-bit nonces and there is no plan to change. So at least for gnutls only the 96-bit nonce version is relevant.
regards, Nikos
Hi,
On Tue, 4 Mar 2014 15:07:03 +0100 Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com wrote:
It has not been approved yet, but the latest TLS proposal for chacha is with 96-bit nonces and there is no plan to change. So at least for gnutls only the 96-bit nonce version is relevant.
I did propose using XChaCha (similar to XSalsa20) to support larger nonces (especially the AEAD recommended 96-bit length), and sticking with plain ChaCha for 64-bit nonces (and allowing them):
http://www.ietf.org/mail-archive/web/cfrg/current/msg04310.html
There should have been a CFRG meeting yesterday, and perhaps it was discussed, but I didn't get any feedback on it yet. If anyone (Nikos?) can report on that I'd be glad to hear about it :)
regards, Stefan
On Tue, Mar 4, 2014 at 3:23 PM, Stefan Bühler nettle-bugs@stbuehler.de wrote:
It has not been approved yet, but the latest TLS proposal for chacha is with 96-bit nonces and there is no plan to change. So at least for gnutls only the 96-bit nonce version is relevant.
I did propose using XChaCha (similar to XSalsa20) to support larger nonces (especially the AEAD recommended 96-bit length), and sticking with plain ChaCha for 64-bit nonces (and allowing them): http://www.ietf.org/mail-archive/web/cfrg/current/msg04310.html There should have been a CFRG meeting yesterday, and perhaps it was discussed, but I didn't get any feedback on it yet. If anyone (Nikos?) can report on that I'd be glad to hear about it :)
Unfortunately I was not there and did not follow the CFRG meeting. I, however, followed (online) the summary of the meeting by David Mcgrew in the TLS WG and the naming wasn't mentioned. The situation on the naming and the exact algorithm details will most probably clear up next month when CFRG provides input to the TLS WG on the chacha cipher.
regards, Nikos
nettle-bugs@lists.lysator.liu.se
-
James Cloos -
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se -
Stefan Bühler