SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: BASE64 and numerical values




    Not always. Sometimes they are  very large prime numbers.  Julo


    pat_thaler@agilent.com

    05/21/2002 07:46 PM
    Please respond to pat_thaler

           
            To:        Julian Satran/Haifa/IBM@IBMIL, rsnively@Brocade.COM
            cc:        ips@ece.cmu.edu, wrstuden@wasabisystems.com
            Subject:        RE: iSCSI: BASE64 and numerical values

           


    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
    >
    >






Home

Last updated: Tue May 21 18:18:31 2002
10187 messages in chronological order