Subject: iSCSI: SRP s vs. S

From: [email-masked]
Date: Wed, 3 Jul 2002 14:53:41 -0400

> > > 10.4 SRP: N,g,s,A,B,M and H(A | M | K) are binary-values
> > > 10.5 CHAP: C and R are binary-values
> > 
> > The only ones of these that should routinely fit in 64 bits are SRP's
> > g (usually a small integer, even though it's mathematically a member of
> > a very large binary field - I think Paul Koning missed the fact that
> > generators tend to be single-digit numbers) and s (doesn't need to be
> > a large number to get the job done). 
> 
> You're right about g.  As for S, it's the result of an exponentiation
> modulo N, so it's no more likely to be a small integer than the other
> SRP intermediate values.  Note that values supplied by the other end
> are involved (as in conventional D-H) so you don't have the ability to
> constrain your implementation to produce small S values.

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.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Paul Koning <[email-masked]>
Date: Wed, 3 Jul 2002 15:27:54 -0400

> 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