RE: iSCSI: BASE64 and numerical values

[pat_thaler@agilent.com]

Julian,

 

Don't the large cryptographic strings represent the coefficients of binary polynomials? I think those are binary values rather than numerical ones so it makes sense to restrict the base64 to binary objects as Bill suggests.

 

Regards,

Pat

 

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, May 21, 2002 9:08 AM
To: Robert Snively
Cc: ips@ece.cmu.edu; 'Bill Studenmund'
Subject: RE: iSCSI: BASE64 and numerical values

And ignore 
completely the needs of some cryptographic protocols for large numerical values? 
  
I do not see why 6 bit values are 
more difficult to handle than 4 or 8 bit ones. 

Julo

Robert Snively <rsnively@brocade.com> 05/21/2002 06:13 PM Please respond to Robert Snively

To:        "'Bill Studenmund'" <wrstuden@wasabisystems.com>, Julian Satran/Haifa/IBM@IBMIL         cc:        ips@ece.cmu.edu         Subject:        RE: iSCSI: BASE64 and numerical values

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:wrstuden@wasabisystems.com]
> Sent: Monday, May 20, 
2002 2:54 PM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> 
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
> 
>