SHA256 fixes

[neocturne]

The first commit is just cleanup.

The second commit fixes a misaligned buffer read, which causes incorrect computation of hashes on architectures with alignment requirements. This fixes the autoupdater failure on kirkwood (ARMv5TE) reported in freifunkMUC/site-ffm#415.

[T-X]

Nice catch! Any idea why the data pointer to ecdsa_sha256_update() was not aligned, was not starting on word size boundaries, in the first place? Does GCC for these architectures not align uint8_t arrays to word size boundaries?

Also, would have expected things to just need more CPU instructions and not to cause different results...

[neocturne]

Nice catch! Any idea why the data pointer to ecdsa_sha256_update() was not aligned, was not starting on word size boundaries, in the first place? Does GCC for these architectures not align uint8_t arrays to word size boundaries?

Also, would have expected things to just need more CPU instructions and not to cause different results...

@T-X A uint8_t array has the same alignment as a single uint8_t, which is 1. This is independent of the architecture (or more precisely, the ABI) - alignment differences between ABIs usually start at primitive types of size 8 or larger.

Accessing a misaligned value (without things like the packed attribute, which sets the alignment of a type to 1) generally is undefined behavior in C. x86 is one of the architectures that don't really care about alignment, but on many archs you'll either get a trap (crashing the process, or allowing the kernel to emulate the access), or an unspecified result (which is the case on ARMv5).

In the case of ecdsautils' SHA256 implementation, the misalignment can occur in two different ways:

• The original data pointer passed into ecdsa_sha256_update() can already be unaligned. This is valid for the API, as a void * doesn't have any alignment requirements.
• ecdsa_sha256_update() processes data in 64 byte blocks. This is done by accumulating data from multiple calls to the function in a buffer in the context. If more bytes than fit in the buffer are submitted in a single call, first the buffer is filled up and processed, and data is adjusted to point to the next unprocessed byte. If the remaining space in the buffer was not divisible by 4, the new data pointer would be misaligned even if it was originally aligned when passed into ecdsa_sha256_update() .

[blocktrron]

Look good, just one thought from me. "Because i don't like it" counts as a valid answer.