RE: iSCSI: BASE64 and numerical values

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Wed, 22 May 2002, Martin, Nick (Server Storage) wrote:

> Julo,
>

> Although it is more compact than hex which encodes 1/2 byte at a time,
> b64 encodes 3/4 of a byte at a time.  When encoding b64 strings, one
> normally processes three bytes at a time, low addressed byte first.
> When encoding and decoding numbers on little endian to b64, perhaps
> the process is straight forward, but I am not sure.  I am sure it is
> extra code relative to hex for handling lengths not a multiple of 3
> bytes.  If any implementation is allowed to send numbers in b64, then
> all must have capability to accept them whenever parsing for a number.
> This is a third redundant encoding for a number.  We could operate
> effectively with only one (hex).  The single code path would be well
> tested.  I expect several implementations (including my own) to have
> flaws in their first attempt at b64 encoding or decoding for numbers
> of arbitrary length.  I don't expect anyone to have flaws in their
> hexadecimal handling.

I'd like us to be able to keep decimal, at least for "small" numbers as we
mention in the spec now. While I agree that adding b64 encoding for
numbers would be new/untested code, I think that decimal is ok; strtoull()
should be a well-tested library routine. :-)

> I have seen discussion about not allowing excess leading zeroes.
> This defeats inferring the correct storage size of a number from its
> encoding.  Outside of security, the sizes of numbers are already fixed
> and this is not a problem.  Within security, I am not sure this is
> true.  (I am nothing like a security expert yet.)

Turns out CHAP needs strings, not numbers, so it is fine. I'm not sure
about SRP, but from what I can tell, all of the other security methods
will be exchanging (from iSCSI's point of view) binary strings.

> Another confusion factor is numbers of arbitrary length.  Without
> knowing the format required internally by security algorithms which
> use these, I am not sure whether they will want big endian or little
> endian format on little endian hardware.  I hope they in fact want a
> b64 or hex representation in big endian a.k.a. network byte order (a
> string) and convert it to internal format themselves.  Suppose the
> algorithm wants a string in hex, but I receive a string in b64!
> Whether these are used internally as numbers or strings is not
> relevant if they are always delivered to the algorithms as strings.

Agreed, and I think we are there (just not sure on SRP).

> Although I use decimal rather than hex today, I would be willing to
> give it up for simpler implementations.

strtoull() is hard? :-)

Take care,

Bill