Message-ID: <000101ce0eca$3a9e7950$afdb6bf0$@acm.org>
Date: Tue, 19 Feb 2013 09:54:54 -0800
From: "Dennis E. Hamilton" <dennis.hamilton@....org>
To: <discussions@...sword-hashing.net>
Subject: RE: [PHC] Coding of the in[inlen] array for PHS( )

+1

The problem I had was with "network byte order" as a term of art here.  I
sense violent agreement.

I agree that the "big-endian" interpretation of in[inlen], salt[] and out[]
as representing a stream of bits is the only one that works and it is common
in specification of security primitives.  

It is better to not use the term though, and be specific about what the
abstract string of bits is relative to the C Language model, since that's
the API signature and contract.  That's what my TL;DR offering was about.

 - Dennis

PS: For me, big-endian is about interpretation of (specific-length) bit
strings as carriers for binary numerals, not about raw strings of contiguous
bits.  I expect that a specification based on blocking into words on which
arithmetic, masking, and shifting are done will be under a big-endian (and
2s complement) assumption.  

PPS: I should get a T-shirt that says I'm a "little-endian veteran of the
big-endian wars."  There is no earthly reason to specify word-sized
crypto-function operations in any other way than by what is called
big-endian representation.

-----Original Message-----
From: Larry Bugbee [mailto:bugbee@....com] 
Sent: Tuesday, February 19, 2013 00:08
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Coding of the in[inlen] array for PHS( )

Hi Dennis,

First let me say I agree with the proposed numeric representations, we only
deal with bytes, and all encoding transformations happen external to PHS()
such that only agnostic bytes are fed to the algorithm.

...to which I would add a requirement the input bytes be in network byte
order (big endian) as it is arguably the more neutral byte order (little
endian can have several variants).  ...and the exact format of the stored
hashes be likewise specified so implementations on other-endian CPUs can
safely use the file/DB.  ...and like RFCs and the NIST docs, perhaps we not
speak of bytes but octets?

My preference for a specification of a byte order is motivated in part by
previous problems when building big endian implementations of algorithms
that were specified in terms of 32-bit little endian word operations.  In
one case, an encryption algorithm, I got my code to work against the
published test vectors, but it failed in the real world.  After a lot of
frustration (debugging) the cause turned out to be the vector bytes were
*already* in little endian byte order, but unspecified as such.  To make a
long story short, I had to fight endianness issues all the way thru the
algorithm without the benefit of reliable test vectors or another big endian
implementation as a reference.  (Sorry, this was years ago and I do not
remember which algorithm.  If it comes to me I'll share.)

That said, internal algorithm details are the province of the designer, but
I believe all interface details should be unambigiously specified if we want
interchangeability.  

Larry


----------------------------------------------------------------------------
------
On Feb 18, 2013, at 6:36 PM, "Dennis E. Hamilton" <dennis.hamilton@....org>
wrote:

> @Larry,
> 
> That makes perfect sense to me but I don't understand the addendum about
> network byte order.
> 
> What does network byte order mean in the context of a C Language array in
> storage?  Is that the same as ordering in[0], in[1], ..., in[inlen-1] and,
> with regard to accepting serial input from a byte stream, the array is
> filled with the first arrival at in[0], the second at in[1], etc.?
> 
> I assume this is the mapping that is also sensible with regard to how
digest
> algorithms are specified in terms of storage blocks.  (If there is a
> big-/little-endian assumption on framing these into multi-byte logical
> words, that is for the interior of the implementation to deal with, in my
> understanding.)
> 
> Is there something that I am missing in what you are saying?
> 
> - Dennis
> 
> -----Original Message-----
> From: Larry Bugbee [mailto:bugbee@....com] 
> Sent: Monday, February 18, 2013 15:57
> To: discussions@...sword-hashing.net
> Subject: Re: [PHC] Coding of the in[inlen] array for PHS( )
> 
> On Feb 18, 2013, at 3:00 PM, Solar Designer <solar@...nwall.com> wrote:
>> In PHS(), we deal with bytes.
> 
> +1
> 
> ...and said bytes/byte strings/byte arrays should be specified to be in
> network byte order.
> 
> 

Powered by blists - more mailing lists