Subject: iSCSI base64 and 12-92

From: "Julian Satran" <[email-masked]>
Date: Thu, 23 May 2002 17:07:01 +0300

Dear colleagues,

I looked again at cryptography needs and I think that large numbers will 
be needed and base64 is a decent and not invented here way to express 
them.

As we have to keep them for numbers I reinstated them for small values too 
(why implement a check) and for those that don't take
numerical big-endian representation for granted there is now text that 
says it  without referring to internal representation.

I think that mapping to addresses is entirely an implementation issue.

All this is in 12-92.

We are still busy polishing the authentication stuff.

Julo

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 23 May 2002 08:55:47 -0700 (PDT)

> be needed and base64 is a decent and not invented here way to express

Just curious, which alogorythm needs them?

Take care,

Bill

---

From: "Michael Krueger" <[email-masked]>
Date: Thu, 23 May 2002 10:06:48 -0700

> says it  without referring to internal representation.

Retaining base-64 encoding for normal-sized numbers (size less than or equal
to the machine's largest arithmetic word size, usually 32 or 64 bits) may
make the language in the spec simpler, but it does NOT simplify
implementation by eliminating a check; in fact, it would require additional
checks and implementation complexity.

Keys that can contain large numbers (larger than the machine's largest
arithmetic word size) must be handled differently from normal-sized numbers
anyway, precisely because they are beyond the machine's normal arithmetic
capabilities; therefore, a check based on the key type must be done no
matter what.  If the spec requires support for base-64 encoding for
normal-sized numbers, implementers will also have to check for the "0b"
prefix, pass the string off to a base-64 decoding routine (taking care not
to overflow the machine's word size), and then properly pad, byte-swap, and
cast the result, or, if "0b" was not found, call strtol() instead.  This
seems like needless implementation complexity to support something NOBODY
will do, i.e., specify a normal-sized number like MaxConnections in base 64!
If the base-64 requirement for normal-sized numbers were dropped, a single
call to strtol() would suffice.

In short, let's keep it simple: decimal and hexadecimal representations for
normal-sized numbers, hexadecimal and base-64 representations for binary
items and large-sized numbers.  (I would still argue that "large-sized
numbers" are just a special case of binary items, but that's a fine point.)

Michael

--
Michael J. Krueger              mailto:[email-masked]
Wind River Networks                         http://www.windriver.com
500 Wind River Way                               phone: 510-749-2130
Alameda, CA  94501                                 fax: 510-749-2010

---

From: Paul Koning <[email-masked]>
Date: Thu, 23 May 2002 12:57:44 -0400

> Just curious, which alogorythm needs them?

I was wondering the same.  Quite possibly I muddled things by talking
earlier about cases that don't actually appear in iSCSI.  The ones
that DO appear in iSCSI all involve strings, not numbers.  (That
includes SRP -- it uses large integers at some steps of the algorithm,
but externally at the protocol level it is specified in terms of
strings.) 

Apart from that, I don't see any reason at all why that means we
should allow Base64 for "ordinary" integers.  I remember a number of
comments objecting to that idea and none in favor of it, nor any
reason why it should be done.  So why do it?

       paul