amosnier / sha-2 Goto Github PK

View Code? Open in Web Editor NEW

177.0 9.0 40.0 58 KB

SHA-2 algorithm implementations

License: Other

Makefile 1.04% C 98.96%

cryptography secure hash algorithm sha256 c portable self-contained embedded-c review

sha-2's Introduction

sha-2

SHA-2 algorithm implementations.

At the moment, only SHA-256 is implemented.

Design criteria

C99
Easy to test, include in any project, compile and link.
Portable. Makes no assumptions on the target system's endianess or word size.
The SHA-256 implementation is a straightforward implementation of the algorithm specified on Wikipedia.

Streaming API

In response to an enhancement request, a new streaming API has been created.

The following code is a silly but complete example:

struct Sha_256 sha_256;
uint8_t hash[32];
sha_256_init(&sha_256, hash);
sha_256_write(&sha_256, "ab", strlen("ab"));
sha_256_write(&sha_256, "c", strlen("c"));
sha_256_close(&sha_256);

That is the equivalent of the (of course still supported) legacy way:

uint8_t hash[32];
calc_sha_256(hash, "abc", strlen("abc"));

See header file for more information.

Since the streaming API is a generalization of the non-streaming one, the latter has been ported to the former, without measurable performance impact. However, a legacy branch has been created in order to make the legacy implementation easily available. If you can measure a significant difference between the two, please post an issue.

Notes

The Makefile is as minimal as possible. No effort was put into making it general. Its purpose is mainly to ease testing for the developer's host machine. The actual implementation is however extremely easy to include in any project, may it use GNU make or any other build tool.

Code review

This code has been reviewed at Stack Exchange CODE REVIEW, and the implementation has been improved accordingly.

Testing

Testing is continuously performed on Travis CI (see above).

Apart from that, the implementation has been successfully tested on an x86-64 machine under Linux as well as on a 16-bit DSP. On the x86-64 machine, all the available NIST test vectors where successfully tested (SHA-256 examples and SHA-2 Additional examples, plus a few others).

In particular:

Input Message: "abc"
Message Digest is BA7816BF 8F01CFEA 414140DE 5DAE2223 B00361A3 96177A9C B410FF61 F20015AD

Input Message: "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq"
Message Digest is 248D6A61 D20638B8 E5C02693 0C3E6039 A33CE459 64FF2167 F6ECEDD4 19DB06C1

SHA-256 Test Data
#1) 1 byte 0xbd
68325720 aabd7c82 f30f554b 313d0570 c95accbb 7dc4b5aa e11204c0 8ffe732b
#2) 4 bytes 0xc98c8e55
7abc22c0 ae5af26c e93dbb94 433a0e0b 2e119d01 4f8e7f65 bd56c61c cccd9504
#3) 55 bytes of zeros
02779466 cdec1638 11d07881 5c633f21 90141308 1449002f 24aa3e80 f0b88ef7
#4) 56 bytes of zeros
d4817aa5 497628e7 c77e6b60 6107042b bba31308 88c5f47a 375e6179 be789fbb
#5) 57 bytes of zeros
65a16cb7 861335d5 ace3c607 18b5052e 44660726 da4cd13b b745381b 235a1785
#6) 64 bytes of zeros
f5a5fd42 d16a2030 2798ef6e d309979b 43003d23 20d9f0e8 ea9831a9 2759fb4b
#7) 1000 bytes of zeros
541b3e9d aa09b20b f85fa273 e5cbd3e8 0185aa4e c298e765 db87742b 70138a53
#8) 1000 bytes of 0x41 ‘A’
c2e68682 3489ced2 017f6059 b8b23931 8b6364f6 dcd835d0 a519105a 1eadd6e4
#9) 1005 bytes of 0x55 ‘U’
f4d62dde c0f3dd90 ea1380fa 16a5ff8d c4c54b21 740650f2 4afc4120 903552b0
#10) 1000000 bytes of zeros
d29751f2 649b32ff 572b5e0a 9f541ea6 60a50f94 ff0beedf b0b692b9 24cc8025
#11) 0x20000000 (536870912) bytes of 0x5a ‘Z’
15a1868c 12cc5395 1e182344 277447cd 0979536b adcc512a d24c67e9 b2d4f3dd
#12) 0x41000000 (1090519040) bytes of zeros
461c19a9 3bd4344f 9215f5ec 64357090 342bc66b 15a14831 7d276e31 cbc20b53
#13) 0x6000003e (1610612798) bytes of 0x42 ‘B’
c23ce8a7 895f4b21 ec0daf37 920ac0a2 62a22004 5a03eb2d fed48ef9 b05aabea

License

This repository is made available under a permissive license. See LICENSE FILE.

Reference implementation

I had missed that when I made this implementation but RFC 6234, chapter 8 actually includes a reference implementation in C that is (at least in ambition) broader in scope than this one. I have however neither compiled nor tested it.

sha-2's People

Contributors

Stargazers

Watchers

sha-2's Issues

Possible memory optimization

Hello,
when computing w[] array in https://github.com/amosnier/sha-2/blob/master/sha-256.c#L168, only last 16 entries are necessary and only w[round] is used in compression loop.
Splitting compression function into 4*16 nested loop will allow computing next w[16] entries on the fly, considerably reducing stack usage (192 bytes saved), with small performance impact ...

Large messages unusable (too big for stack allocation)

I couldn't compile for some time... Took me a few minutes to realize that line 44 in test.c with define
#define LARGE_MESSAGES 1
won't really work on Windows with its 1mb stack limit... After changing it to 0, everything compiled as it should.

It should be noted somewhere in ReadMe or made compile-time specific for Windows (don't allow it at all or something).
Other solution would be to make it allocate on heap at run-time.

EDIT: I quite misread the actual sizes. 1gb on stack? Wow, that is some giant stack...
These should definitely be heap-allocated!

Why include the .h in the repo?

I found your implementation and goals here. This is exactly what I was looking for! Something like Keccak standalone files where you only have to include the .c and don't even have to edit your makefile. I guess I could do the same with yours so the question is: why include the .h in the repo?

Add a streaming API for computing SHA-256.

This API could be useful for computing checksum of a file without storing all of the file's data in the memory, or checksumming 2 strings together without concatenating them. Example -

const char *a = "hello,";
const char *b = " world!";
uint8_t hash[32];

sha256_ctx_t ctx;
sha256_init(&ctx);
sha256_update(&ctx, a, strlen(a));
sha256_update(&ctx, b, strlen(b));
sha256_final(&ctx, hash);

Problem with format string

You have a little typo in your format string in test.c at line 184

This:
printf("input starts with 0x%02x, length %lu\n", *input, input_len);
...should be this:
printf("input starts with 0x%02x, length %zu\n", *input, input_len);

Although z switch is C99 addition....

Problem lies in that that you assume that size_t is long unsigned but it is indeed whatever compilers treats it as.
z switch can be used to tell compiler input is of type size_t which is the right way to do.

You can do the same with compile time check if you want to be pre-C99 conformant but this should definitely be fixed, as it is undefined behavior and could cause memory leak.

Memory leak? valgrind is not happy.

I directly cloned the repository, ran make and ran the test binary on Linux kondenzator 5.3.0-53-generic #47~18.04.1-Ubuntu SMP Thu May 7 13:10:50 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux.

a@kondenzator:/tmp/sha-2$ valgrind -v ./test > valgrind-output.txt 2>&1
Killed
a@kondenzator:/tmp/sha-2$ cat valgrind-output.txt 
==10564== Memcheck, a memory error detector
==10564== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==10564== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==10564== Command: ./test
==10564== 
--10564-- Valgrind options:
--10564--    -v
--10564-- Contents of /proc/version:
--10564--   Linux version 5.3.0-53-generic (buildd@lgw01-amd64-016) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #47~18.04.1-Ubuntu SMP Thu May 7 13:10:50 UTC 2020
--10564-- 
--10564-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-sse3
--10564-- Page sizes: currently 4096, max supported 4096
--10564-- Valgrind library directory: /usr/lib/valgrind
--10564-- Reading syms from /tmp/sha-2/test
--10564-- Reading syms from /lib/x86_64-linux-gnu/ld-2.27.so
--10564--   Considering /lib/x86_64-linux-gnu/ld-2.27.so ..
--10564--   .. CRC mismatch (computed 1b7c895e wanted 2943108a)
--10564--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.27.so ..
--10564--   .. CRC is valid
--10564-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--10564--   Considering /usr/lib/valgrind/memcheck-amd64-linux ..
--10564--   .. CRC mismatch (computed 41ddb025 wanted 9972f546)
--10564--    object doesn't have a symbol table
--10564--    object doesn't have a dynamic symbol table
--10564-- Scheduler: using generic scheduler lock implementation.
--10564-- Reading suppressions file: /usr/lib/valgrind/default.supp
==10564== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-10564-by-a-on-???
==10564== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-10564-by-a-on-???
==10564== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-10564-by-a-on-???
==10564== 
==10564== TO CONTROL THIS PROCESS USING vgdb (which you probably
==10564== don't want to do, unless you know exactly what you're doing,
==10564== or are doing some strange experiment):
==10564==   /usr/lib/valgrind/../../bin/vgdb --pid=10564 ...command...
==10564== 
==10564== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==10564==   /path/to/gdb ./test
==10564== and then give GDB the following command
==10564==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=10564
==10564== --pid is optional if only one valgrind process is running
==10564== 
--10564-- REDIR: 0x401f2f0 (ld-linux-x86-64.so.2:strlen) redirected to 0x580608c1 (???)
--10564-- REDIR: 0x401f0d0 (ld-linux-x86-64.so.2:index) redirected to 0x580608db (???)
--10564-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so
--10564--   Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--10564--   .. CRC mismatch (computed 50df1b30 wanted 4800a4cf)
--10564--    object doesn't have a symbol table
--10564-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--10564--   Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--10564--   .. CRC mismatch (computed f893b962 wanted 95ee359e)
--10564--    object doesn't have a symbol table
==10564== WARNING: new redirection conflicts with existing -- ignoring it
--10564--     old: 0x0401f2f0 (strlen              ) R-> (0000.0) 0x580608c1 ???
--10564--     new: 0x0401f2f0 (strlen              ) R-> (2007.0) 0x04c32db0 strlen
--10564-- REDIR: 0x401d360 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c33ee0 (strcmp)
--10564-- REDIR: 0x401f830 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c374f0 (mempcpy)
--10564-- Reading syms from /lib/x86_64-linux-gnu/libc-2.27.so
--10564--   Considering /lib/x86_64-linux-gnu/libc-2.27.so ..
--10564--   .. CRC mismatch (computed b1c74187 wanted 042cc048)
--10564--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.27.so ..
--10564--   .. CRC is valid
--10564-- REDIR: 0x4edac70 (libc.so.6:memmove) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ed9d40 (libc.so.6:strncpy) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4edaf50 (libc.so.6:strcasecmp) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ed9790 (libc.so.6:strcat) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ed9d70 (libc.so.6:rindex) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4edc7c0 (libc.so.6:rawmemchr) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4edade0 (libc.so.6:mempcpy) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4edac10 (libc.so.6:bcmp) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ed9d00 (libc.so.6:strncmp) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ed9800 (libc.so.6:strcmp) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4edad40 (libc.so.6:memset) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ef80f0 (libc.so.6:wcschr) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ed9ca0 (libc.so.6:strnlen) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ed9870 (libc.so.6:strcspn) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4edafa0 (libc.so.6:strncasecmp) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ed9840 (libc.so.6:strcpy) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4edb0e0 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ed9da0 (libc.so.6:strpbrk) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ed97c0 (libc.so.6:index) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ed9c70 (libc.so.6:strlen) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ee46c0 (libc.so.6:memrchr) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4edaff0 (libc.so.6:strcasecmp_l) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4edabe0 (libc.so.6:memchr) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4ef8eb0 (libc.so.6:wcslen) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4eda050 (libc.so.6:strspn) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4edaf20 (libc.so.6:stpncpy) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4edaef0 (libc.so.6:stpcpy) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4edc7f0 (libc.so.6:strchrnul) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4edb040 (libc.so.6:strncasecmp_l) redirected to 0x4a2a6e0 (_vgnU_ifunc_wrapper)
--10564-- REDIR: 0x4eed330 (libc.so.6:__strrchr_sse2) redirected to 0x4c32790 (__strrchr_sse2)
--10564-- REDIR: 0x4eed620 (libc.so.6:__strlen_sse2) redirected to 0x4c32d30 (__strlen_sse2)
--10564-- REDIR: 0x4ef7460 (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4c34060 (memcpy@GLIBC_2.2.5)
--10564-- REDIR: 0x4ef7870 (libc.so.6:__memset_sse2_unaligned) redirected to 0x4c365d0 (memset)
--10564-- REDIR: 0x4eed120 (libc.so.6:__strchrnul_sse2) redirected to 0x4c37020 (strchrnul)
--10564-- REDIR: 0x4ed3070 (libc.so.6:malloc) redirected to 0x4c2faa0 (malloc)
--10564-- REDIR: 0x4ef7440 (libc.so.6:__mempcpy_sse2_unaligned) redirected to 0x4c37130 (mempcpy)
--10564-- REDIR: 0x4ee5e70 (libc.so.6:__strcmp_sse2_unaligned) redirected to 0x4c33da0 (strcmp)
==10564== Warning: set address range perms: large range [0x562d040, 0x2562d040) (undefined)
==10564== Warning: set address range perms: large range [0x59e43040, 0x9ae43040) (undefined)
==10564== Warning: set address range perms: large range [0x9ae44040, 0xfae4407e) (undefined)

Make the implementation compilable in C++ without error

From https://isoptera.lcsc.edu/seth/cs211/project4.html:

Sha256 is well-defined, and you could certainly start from scratch and write a program for it. But, there are good open implementations around. For this project, I recommend starting with Alain Mosnier's code, available on github here: https://github.com/amosnier/sha-2. On a unix-type system, you can check it out like this:

seth@nimrod:/tmp $ git clone https://github.com/amosnier/sha-2
Cloning into 'sha-2'...
remote: Enumerating objects: 206, done.
remote: Counting objects: 100% (89/89), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 206 (delta 82), reused 74 (delta 74), pack-reused 117
Receiving objects: 100% (206/206), 57.54 KiB | 577.00 KiB/s, done.
Resolving deltas: 100% (120/120), done.

For anyone working on isoptera, that's an easy way to go. Other operating systems might vary a little. If working with online GDB, I'd recommend downloading sha-256.c and sha-256.h and uploading them both as part of a new project. The repository is written in C, and will work fine in C++, with one exception. C++ requires an explicit cast when copying a pointer of type void to a different type, and C does not. So mixing with C++ and building with g++ will lead to an error:

seth@nimrod:/tmp/sha-2 $ g++ 211test.cpp  sha-256.c
sha-256.c: In function 'void sha_256_write(Sha_256*, const void*, size_t)':
sha-256.c:139:28: error: invalid conversion from 'const void*' to 'const uint8_t*' {aka 'const unsigned char*'} [-fpermissive]
  139 |         const uint8_t *p = data;
      |                            ^~~~
      |                            |
      |                            const void*

To fix this, open up sha-256.c to line 139, and make this revision:

const uint8_t *p = (const uint8_t*)data;

After that, it should build. For a C++ test program, download login_system.cpp from the class examples area, and build it together with sha-256.c. Here's an example:

seth@nimrod:/tmp/sha-2 $ g++ login_system.cpp sha-256.c
seth@nimrod:/tmp/sha-2 $ ./a.out
Enter the password:  hamster
Sorry, you don't seem to know the password!

As showed above, while sha-256.c is perfectly valid C, making it compilable in C++ without errors makes sense. Thanks to professor S. Seth Long for pointing this out.

Is sha-2 thread safe ?

Closing with total length may produce incorrect value on smaller systems(?)

I haven't implemented SHA-256 myself, but if I understand your code and the spec correctly, the digest is closed with (among others) encoding the total length in bits. However, IIUC, the size of size_t may be dependent on system architecture. So, size_t could be 32-bits in size on smaller systems.

See total_len in struct Sha_256 and length-encoding in sha_256_close.

(Also, as side-note: I think you need to #include <stddef.h> in sha-256.h for type size_t.)

Getting a different output compared to sha256sum command

I have the following code - all seems to be ok:

#include "sha-256.h"
#include <stdio.h>
#define HASH_LENGTH 32
int main(void)
{
	uint8_t hash[HASH_LENGTH];
	calc_sha_256(hash, "abc", strlen("abc"));
	size_t i;
	for (i = 0; i < HASH_LENGTH; i++)
	{
		printf("%02x", hash[i]);
	}
	puts(""); //new line here
}

However, the sha256sum utility is producing a different output.
what could possibly be wrong with my code?
Regards

Does this work on files?

Is it possible to use this file to verify the sha256sum of a file?
Regards

Dual license the project with Original + public-domain equivalent license

Public-domain is not recognized in many countries outside the United States, particularly in Continental Europe. Due to this, many people would not be able to use this software under the Unlicense.

Therefore it would be great if this software is dual-licensed (or re-licensed) under the Unlicense and BSD Zero Clause License, which is a public-domain equivalent license. This would enable people from Continental Europe to legally use this software without any constraints, just like public domain, while also formally placing it in public-domain in countries that allow it.

To achieve it, the LICENSE.md should contain the following:

# Licensing Information

Except as otherwise noted (below and/or in individual files), this project is
licensed under the [Unlicense](#the-unlicense)
(https://opensource.org/licenses/unlicense) or the [Zero Clause BSD license](#zero-clause-bsd-license)
(https://opensource.org/licenses/0bsd), at your
option.

## The Unlicense

This is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or
distribute this software, either in source code form or as a compiled
binary, for any purpose, commercial or non-commercial, and by any
means.

In jurisdictions that recognize copyright laws, the author or authors
of this software dedicate any and all copyright interest in the
software to the public domain. We make this dedication for the benefit
of the public at large and to the detriment of our heirs and
successors. We intend this dedication to be an overt act of
relinquishment in perpetuity of all present and future rights to this
software under copyright law.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

For more information, please refer to <http://unlicense.org/>

## Zero Clause BSD License

&copy; 2021 Alain Mosnier

Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH
REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT,
INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR
OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.

Why SIZE_OF_SHA_256_HASH macro is not referenced in sha-256.c ?

We know that SIZE_OF_SHA_256_HASH macro is required to define the size of the hash result variable. For example:

uint8_t hash[SIZE_OF_SHA_256_HASH]; // hash result variable: 32 bytes of 8bits each = 256 bits

But none of the functions (sha_256_init(), sha_256_write(), sha_256_close()) make use of this macro.
It seems that those functions internally use a hard coded way to fill the hash variable (provided by the caller) assuming it is a 32 bytes array (even if it is not the case). That looks a bit not consistent. Please, did I miss something ?