hi nettle folks--
the nettle docs say:
In Nettle, most key setup functions have no return value, but for ciphers with weak keys, the return value indicates whether or not the given key is weak.
[...]
A problem is that the key setup of ARCFOUR is quite weak, you should never use keys with structure, keys that are ordinary passwords, or sequences of keys like ``secret:1'', ``secret:2'', ...
[...]
void arcfour_set_key (struct arcfour_ctx *ctx, unsigned length, const uint8_t *key) Initialize the cipher. The same function is used for both encryption and decryption.
Put together, these three statements seem contradictory.
If arcfour has weak keys, shouldn't arcfour_set_key return an int indicating whether the key is considered weak (like the key setup functions for BLOWFISH, DES, and DES3 do)?
Is the problem that there is no clear way to determine if an arcfour key is weak?
--dkg
Daniel Kahn Gillmor dkg@fifthhorseman.net writes:
A problem is that the key setup of ARCFOUR is quite weak, you should never use keys with structure, keys that are ordinary passwords, or sequences of keys like ``secret:1'', ``secret:2'', ...
The problem with arcfour is not that some particular keys are unexpectedly weak, but that the key bits are not spread out very well into the internal state (sorry if this description is a bit vague; my understanding is also a bit vague...).
So there's unexpectedly high correlation between the first bytes of the key and the first bytes of the generated key stream, and I think there's also undesired correlation between key streams for close keys.
I think the recommendations in the manual (hash the key first, and discard the initial bytes of the key stream) are still adequate.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
Daniel Kahn Gillmor dkg@fifthhorseman.net writes:
A problem is that the key setup of ARCFOUR is quite weak, you should never use keys with structure, keys that are ordinary passwords, or sequences of keys like ``secret:1'', ``secret:2'', ...
The problem with arcfour is not that some particular keys are unexpectedly weak, but that the key bits are not spread out very well into the internal state (sorry if this description is a bit vague; my understanding is also a bit vague...).
There are some keys which are even weaker, for example keys beginning with 00 00 FD and 03 FD FC, see this paper:
http://impic.org/papers/WeakKeys-report.pdf
On the other hand, RC4 is broken so the function might as well always return 1 to indicate that the key is weak since it is used with RC4. :-)
/Simon
Simon Josefsson simon@josefsson.org writes:
There are some keys which are even weaker, for example keys beginning with 00 00 FD and 03 FD FC, see this paper:
This still exploits statistical properties of the first few generated bytes, right? So if you generate and discard the first 512 or 1024 bytes or so of the keystream, the statistics for these keys shouldn't be much different from any oter keys, right?
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
Simon Josefsson simon@josefsson.org writes:
There are some keys which are even weaker, for example keys beginning with 00 00 FD and 03 FD FC, see this paper:
This still exploits statistical properties of the first few generated bytes, right?
Yes, that's true.
So if you generate and discard the first 512 or 1024 bytes or so of the keystream, the statistics for these keys shouldn't be much different from any oter keys, right?
Right. I think 512 bytes is a bit on the low end these days, conservative recommendations are now up 3072 bytes:
http://www.users.zetnet.co.uk/hopwood/crypto/scan/cs.html#RC4-drop
Note that the RC4 keystream can be distinguished from random with only about a few GB's of stream output regardless of how many initial bytes are dropped. This suggests to me that there are attacks that will work regardless of how much initial output you discard.
/Simon
nettle-bugs@lists.lysator.liu.se
-
Daniel Kahn Gillmor -
nisse＠lysator.liu.se -
Simon Josefsson