Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [P1619-2] the EME2 ref code vs. byte-oriented pseudocode

In a little-endian system, after you convert the bytes to a block you have to swap the order.  If you padded with 0x80 00 00 00, you'd get this when converting to an integer:

00000080

Left shift or right shift, you've still got the padding bit in a strange place.

Conversely, if you pad with 01 00 00 00, you get:

00000001

which at least keeps all the padded zeros contiguous in the integer representation.

That said, it's easier to explain the 0x80 00 padding scheme, so I could see the virtue in using that method.

(BTW, What is alpha?  If you're using little-endian byte order and defining a 'multiply by alpha' as a left-shift, then alpha would be 02 00 00 00..., which would suggest that using 01 00 00.... padding is better --- 01 00 00.. is the multiplicative identity)

Cheers,
-Matt

On Wed, Jun 18, 2008 at 4:34 PM, Hal Finney <hal.finney@gmail.com> wrote:
On Tue, Jun 17, 2008 at 4:44 PM, Matt Ball <matt.ball@ieee.org> wrote:
> Hi Hal,
>
> Using 0x80 vs. 0x01 is a Big-Endian vs. Little-Endian issue.

Hi Matt - Right, I understand this. As it happens, the multByAlpha
function in EME2 performs *left* shifts of the bits within a byte, so
this would suggest that 0x80 would be most appropriately thought of as
the "next bit" after a byte, for padding purposes.

Hal



--
Thanks!
Matt Ball, IEEE P1619.x SISWG Chair
M.V. Ball Technical Consulting, Inc.
Phone: 303-469-2469, Cell: 303-717-2717
http://www.mvballtech.com
http://www.linkedin.com/in/matthewvball