Re: CHAP secret lengths

[wrstuden@wasabisystems.com]

On Thu, 13 Mar 2003, Dean Scoville wrote:

> Julian,
>
> The MD5 algorithm (RFC 1321) can encode messages that are
> comprised of an arbitrary number of bits, and as such the
> message length need not be a multiple of 8-bits.
>
> The CHAP RFC (RFC 1994) describes the CHAP Response
> value as being a one-way hash calculated over a stream of octets,
> consisting of the Identifier, followed by (concatenated with) the
> "secret",  followed by (concatenated with) the Challenge Value.
>
> This would lead me to believe that the CHAP secret must be an
> integral number of octets, even though the MD5 algorithm is
> capable of encoding messages that are not a multiple of 8-bits
> and even though the iSCSI draft uses units of "bits" (96 random
> bits, 128 bit random secrets, etc.) when referring to acceptable
> CHAP secret lengths.
>
> Can we assume that CHAP secrets will always be a multiple of 8-bits?

Yes. There's no real reason to support fractions of an octet. Also, the
crypto libraries I am familiar with only support hashing a number of
bytes, not bits.

> If not, do we need to pad the secret to a multiple of 8-bits (using
> 0's as pad bits, perhaps?) before concatenating it with the Identifier
> and Challenge values and running the result through the MD5 algorithm?

Note what you describe above is not supporting a secret whose length is
not a multiple of 8-bits, you describe turning such a secret into one
which is a multiple of 8-bits. So the hashing is still only working with
octets. That's something that can be done independently of iSCSI.

Take care,

Bill