Re: [Hashlet-users] HMAC Feature

[Josh Datko]

It appears my reply-to is broken on the list...  bit order rsp inline.

On Sun, Jan 26, 2014 at 7:15 PM, Kyle Isom <address@hidden> wrote:

Sometimes, they will start describing bit 0 first, but bit 0 is the LSB
always.

So byte order is little-endian?

 

I'm not sure it's that straight forward.  Although, I admit, I often

confuse the two.  The following is from the datasheet:

4.1 Byte and Bit Ordering CryptoAuthentication uses a common ordering

scheme for bytes and also for the way in which numbers and arrays are

represented in this datasheet: - All multi-byte aggregate elements are

treated as arrays of bytes and are processed in the order received or

transmitted with index #0 first.  - 2-byte (16-bit) integers,

typically Param2 appear on the bus least-significant byte first.

The bit order is different depending on the I/O channel used: - On the

I2C interface, data is transferred to/from the ATSHA204

most-significant bit first on the bus.

A more concrete example, for the HMAC command:

The on-the-wire data transmission of:

0x11 0x60 0x00 0x01

breaks down into:

0x11 -> opcode 0x60 -> param1 -> 0b01100000 -> bit 6 and 5 are set

0x00 0x01 -> param2 -> use key slot 1 

4. I'm passing struct octet_buffer s around by value on purpose.  They
contain a pointer and a len.  There are functions in util.h to free and
malloc the buffers, which will automatically zero out the data.

Hah, I'm comfortable with both, it's just a matter of getting used to the sub-standard coding style :P

5. When debugging, pass the -v option.  This will dump all the bytes on the
wire and makes debugging a lot easier.  A logic analyzer is nice to have,
but the bare metal I2c stuff seems to be working.

Nice, I've got a logic probe that I've used for debugging I2C in the past, shouldn't be an issue.

Looking forward to getting this knocked out.