Re: keying material

Paul Koning <pkoning@xedia.com> Wed, 27 May 1998 15:16 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21784 for ipsec-outgoing; Wed, 27 May 1998 11:16:13 -0400 (EDT)
Date: Wed, 27 May 1998 11:29:10 -0400
Message-Id: <199805271529.LAA10554@tonga.xedia.com>
From: Paul Koning <pkoning@xedia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: srinu@trinc.com
Cc: ipsec@tis.com
Subject: Re: keying material
References: <3.0.1.32.19980527185440.00690100@172.16.1.10>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

>>>>> "Srinivas" == Srinivas B Kulkarni <srinu@trinc.com> writes:

 Srinivas> Hi SKEYID is a string derived from secret material known
 Srinivas> only to the active players in the exchange.
>...
 Srinivas> when the Hashes are derived from the payload data , I
 Srinivas> assumed that the data that goes into that are in the
 Srinivas> NETWORK Byte order.

 Srinivas> IS IT CORRECT?

Doesn't sound like it.  The hash functions take byte strings as input
(not multibyte fields like integers) so it's not meaningful to talk
about network byte order.  Byte strings only come in one order.

Meanwhile, as I mentioned a month or so ago, it would be useful to
have byte order spelled out.  Right now it's not and this is bound to
cause interoperability problems.  Not so much for the hash functions
(where at least some of the underlying specs are fairly clear) but
more so for things like DES, where it simply is NOT specified.

	paul

keying material Srinivas B Kulkarni
Re: keying material Paul Koning
Re: keying material Srinivas. B. Kulkarni