[227] in cryptography@c2.net mail archive
Re: Key Scheduling vs. Ciphering -- A Hole In Modern Cryptography?
daemon@ATHENA.MIT.EDU (Hal Finney)
Sat Feb 15 13:57:40 1997
Date: Sat, 15 Feb 1997 09:38:34 -0800
From: Hal Finney <hal@rain.org>
To: cryptography@c2.net, reinhold@world.std.com
From: "Arnold G. Reinhold" <reinhold@world.std.com>
> The recent discussion in the cryptography mailing list about key scheduling
> in RC-4/5 and DES suggests to me that key scheduling has been glossed over
> in modern public cryptography. I believe that key scheduling algorithms are
> cryptographic objects in their own right and should be considered
> separately from ciphers.
That's an interesting idea, with a couple of limitations. First, not
all ciphers have internal keys or key schedules as such. Second, some
ciphers may have structure in their internal keys such that you can't
just choose a random key scheduling algorithm. Most do not, though,
having purely random bits in their internal keys, so this idea would
seem valid for those.
> [...]
> For example, designers of a wideband video conferencing system might choose
> RC4 ciphering for it's computational simplicity. However, if they want to
> change keys frequently, RC4's set up might be onerous. Therefore the
> designers might choose a different scheme implementable in hardware without
> iterations. For example, each output bit might be the XOR of, say, 9 input
> bits chosen randomly at design time. (I am not asserting that this would be
> as strong as the RC4 key schedule, but it might do.)
This is an example of the point I was making above. RC4's internal
key table MUST be a permutation of 0..255. Filling it with random
bits will not work and will potentially produce a much weaker cipher.
Now if you have a better way of choosing a (mostly) random permutation
than the standard key scheduler, that would be fine, but I think what
RC4 has is pretty fast for what it needs to accomplish, yet complicated
enough to make it hard to do quickly in hardware, both desirable traits.
> As far as I know, developing key schedulers that maximize the cost to
> searchers while minimizing the burden for users has not received much
> attention.
One of the PKCS papers from RSA has a suggested algorithm for multiply
hashing a pass phrase to produce a key, although not an internal key.
Hal
