Subject: RE: iSCSI: BASE64 and numerical values

From: Robert Snively <[email-masked]>
Date: Tue, 21 May 2002 08:13:33 -0700

I have been having continuing problems understanding why
iSCSI is considering any use of base64, and I find myself
in total agreement with Bill's clear exposition of the
situation.

Upon reviewing RFC-2045, it is clear that base64 is a method
for containing handy binary values in a EMAIL structure that does
not use TCP/IP to transmit data, but rather uses obsolete
7-bit ASCII or (slightly less obsolete) EBCDIC strings to 
carry the data.  TCP/IP transmits data neutral octets, 
so binary values can be carried in their native binary 
string format (allowing for a possible requirement to pad
strings to an octet boundary).  The most standard way to
present those binary strings on a printer or as an input
value to a program is hexadecimal encoding.

For those reasons, I agree with Bill that we should delete
base64 from the text and use hexadecimal as he suggests.

Bob

> -----Original Message-----
> From: Bill Studenmund [mailto:[email-masked]]
> Sent: Monday, May 20, 2002 2:54 PM
> To: Julian Satran
> Cc: [email-masked]
> Subject: Re: iSCSI: BASE64 and numerical values
> 
> 
> On Sat, 18 May 2002, Julian Satran wrote:
> 
> > Yes for regular numerical values it makes sense. We will 
> have to keep it
> > for large numerical values used for cryptography.  Julo
> 
> I realize I'm driving a semantic nit, but I don't think we should use
> BASE64 for any "numeric" values, only "binary" ones. I 
> believe we probably
> agree on what we want, I'm just worried that if the wording isn't 100%
> tight, the decode path can become a real mess (since we're 
> supposed to be
> liberal in what we accept :-).
> 
> I'd like to suggest we drop BASE64 from the text that 
> mentions numerical
> values. I really don't look forward to byteswapping a 256 or 512 bit
> number as part of BASE64 decode. :-)
> 
> I'd also like to suggest that for encoding large binary values using
> hexadecimal, we state that the hexadecimal representation is 
> that of the
> number in network byte order. i.e. if I have the five octets 
> 02 45 78 ab
> de, the hex constant is 0x024578abde. That makes the decode logic REAL
> easy; grab two hex characters & convert to one octet. Repeat 
> as needed.
> Please note that this is not the output you'd get with something like
> printf("0x%x", number) on a little-endian machine.
> 
> Thirdly, I'd like to suggest we drop decimal support from 
> binary objects.
> It too has the cumbersome byte-swapping issue that I started 
> this thread
> about, just in reverse. :-)
> 
> I realize that's a lot for one EMail. :-)
> 
> To try and be proactive about this, I'd like to suggest 
> revised text for
> section 4.1 (of course needs word-wrapping). For the definitions:
> 
>      hex-constant: hexadecimal constant encoded as a string start-
>        ing with "0x" or "0X" followed by 1 or more digits or the
>        letters a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants
>        are used to encode numerical values or binary strings. When
>        used to encode numerical values the excessive use of leading
>        0 digits is discouraged. When used to encode binary strings
>        hexadecimal constants must have an even number of digits,
>        and have an implicit byte-length that
>        includes 4 bits for every hexadecimal digit of the constant,
>        including leading zeroes (i.e., a hex-constant of n hexadeci-
>        mal digits has a byte-length of n/2). Additionally, when used
>        to encode binary strings, hexadecimal constants shall be
>        expressed in network byte order (i.e., the octet stream 02
>        45 78 ab de would be expressed as "0x024578abde").
> 
>      decimal-constant: an unsigned decimal number - the digit 0 or a
>        string of 1 or more digits starting with a non-zero digit.
>        This encoding is not used for numerical values equal or
>        greater than 2**64.
> 
>      base64-constant: base64 constant encoded as a string starting
>        with "0b" or "0B" followed by 1 or more digits or letters or
>        plus or slash or equal. The encoding is done according to
>        [RFC2045]. base64-constants are used to encode binary strings.
>        Base64-constants have an implicit byte-length that includes 6
>        bits for every character of the constant excluding trailing
>        equals (i.e., a base64-constant of n base64 characters
>        excluding the trailing equals and m trailing equals has a
>        byte-length of ((the integer part of) ((n+3)*3/4) - m).
> 
>        regular-numerical-value :  an unsigned integer less than 2**64
>          encoded as a decimal-constant, or hex constant.
> 
>        large-numerical-value :  an unsigned integer larger than or
>          equal to 2**64 encoded as a hex constant.
> 
> [no change for numerical-value or numerical-range]
> 
>        binary-value :  a binary string encoded as a hex-con-
>          stant or base64-constant.  The length of the string is either
>          specified by the key definition or is implicit byte-length of
>          the encoded string.
> 
> [delete regualar-binary-value and large-binary-value since 
> the distinction
> is gone]
> 
> I don't see it explicitly mentioned anywhere, but I think all 
> of the CHAP
> (and SRP, but not sure) keys are large numericalal values, and the
> kerberos and SPKM keys are binary values.
> 
> Also, I think the CHAP keys need the field length features of 
> hexadecimal
> binary strings, but they are numbers, not binary strings. Not 
> sure how to
> word that.
> 
> Take care,
> 
> Bill
> 
>

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 21 May 2002 09:27:33 -0700 (PDT)

> base64 from the text and use hexadecimal as he suggests.

I must not have been totally clear. I'm not suggesting we remove base64,
I'm suggesting we limit its use to the cases where (IMHO) it makes sense.
While there will be much fewer cases in the text with the changes I
suggest, it will still be in the spec.

Some of the cryptographic authentications throw around large binary
strings. Quite large (compared to the numbers and strings we often use)
binary strings. The fact that if you support these modes of authentication
you are supposed to be able to accept four times as much text in login
commands reflects the size of these strings.

Base64 is a real win for these. Hex can encode 4 bits per byte, while
base64 can encode 6. Thus an n byte string will be about 1.33*n bytes in
base 64, while it will be 2n bytes in hex. That size difference is why we
want base64.

The main point I've been trying to make is that binary strings and numbers
are different things, and that encoding methods for one aren't really
appropriate for the other. Specifics: decimal & hex work great for
numbers, and hex and base64 work great for binary strings. That's it.
Also, the hex for numbers isn't the same as the hex for binary strings.
One is the number in hex, the other is more like hexdump -x without the
spaces and without the offsets.

Take care,

Bill