Re: iSCSI: SRP s vs. S

[Paul Koning <ni1d@arrl.net>]

Excerpt of message (sent 3 July 2002) by Black_David@emc.com:
> Paul - please recheck RFC 2945, as you may have confused s (lower case)
> with S (upper case).  s (lower case) is the <salt from passwd file> and
> is what goes across the wire.  S (upper case) is an intermediate in the
> SRP computations that should be identical on both sides, but is *not*
> sent across the wire (good thing too, as the session key(s) can easily
> be determined from knowledge of it).  s (lower case) need not be a big
> number to get the job done, and would be ok to send in decimal, although
> my first reaction to "salt from passwd file" would be to use hex.

You're right,  I did mix up s and S.

"s" is used as a string (in a SHA1 hash) so it is crucial to get its
length correct.  Decimal numbers don't have an obvious length, as has
been pointed out before, so that representation should not be used
here.

I pointed out earlier that the way to look at this is: there are two
data types, integer and octetstring.  "Integer" means machine integer,
not bignum.  All crypto items with the possible exception of "g" are
either octetstrings (hash inputs or outputs) or they are bignums.

Octetstrings should use hex or base64 but not decimal; integers should
use decimal or hex but not base64.

We've more or less agreed on this before, except that things remain
muddled because the data type distinction hasn't been made.  I think
it would help if it were, though arguably that's editorial.

A separate question is whether "machine integer" should be 32 bits, or
64 bits.  All the current integer keys fit in 32 bits with lots of
room to spare, so there isn't any good reason to require support for
64 bit integers since they won't be used.  If the type distinction
between octetstrings and integers is made, then the issue of (with
very low probability) being able to send crypto values as 64 bit
integers disappears, which would be a Good Thing.

	 paul