I cannot get the SHA-256 hasher to produce correct results using the sha256_ctx_mgr* API #14

New issue

Open

opened 2018-08-14 09:32:36 -05:00 by SteelBlueVision · 1 comment

SteelBlueVision commented

2018-08-14 09:32:36 -05:00

(Migrated from github.com)

This is true when I have to compute the SHA256 hash in multiple steps. Here is the pseudo-code for what I am doing:

Call sha256_ctx_mgr_init to initialize a context manager.
Call hash_ctx_init() on a SHA_256_HASH_CTX object to initialize a hash context for use with the context manager.
Call sha256_ctx_mgr_submit() on the first data chunk, supplying the hash context from Step 2, the data buffer to be hashed, the length of the data, and the flag HASH_FIRST, indicating that this is the first chunk of several.
The return value of sha256_ctx_mgr_submit() is nullptr at this point, since the hashing has been queued and is in progress. To make matters simple, I am using a synchronous flow with one context at the moment. So, in order to wait for synchronous compleition of the hash request, I call sha256_ctx_mgr_flush() on the context manager. This returns the pointer to my SHA_256_HASH_CTX object, whose error member indicates HASH_CTX_ERROR_NONE and whose status member indicates HASH_CTX_STS_IDLE. To me this indicates that the context manager is ready to cache the next chunk of the data using the hash context.
I continue to send in the remaining chunks just as in Step 3, except with the HASH_CTX_FLAG set to HASH_UPDATE for each subsequent chunk (except the last, which I will describe in the next step). After each submit, I await hashing completion using sha256_ctx_mgr_flush() which returns back my context.
I submit the last chunk as in step 3 except with the flag HASH_LAST. I then do a final sha256_ctx_mgr_flush() and look at the SHA256 hash data in the context's job.result_digest. This data gets reordered from big endian to little endian on each 32-bit word (e.g., 0x0a0b0c0d becomes 0x0d0c0b0a for each 32-bit word of the hash) and finally the hash is displayed in hex. This should produce a valid hash and in fact does as described below for the simple case of a single chunk.

Important exception and notes: The hash is correct if I submit a single chunk with the flag HASH_ENTIRE, regardless of the size of the chunk. Unfortunately, if I break up the data and submit it in multiple chunks (HASH_FIRST, HASH_UPDATE..., HASH_LAST), using the methodology in the steps above, the hash produced is incorrect and in no way resembles the correct expected hash as indicated by for example the sha256sum utility.

Please look at my steps above and tell me what I am doing wrong.

This is true when I have to compute the SHA256 hash in multiple steps. Here is the pseudo-code for what I am doing: 1. Call sha256_ctx_mgr_init to initialize a context manager. 2. Call hash_ctx_init() on a SHA_256_HASH_CTX object to initialize a hash context for use with the context manager. 3. Call sha256_ctx_mgr_submit() on the first data chunk, supplying the hash context from Step 2, the data buffer to be hashed, the length of the data, and the flag HASH_FIRST, indicating that this is the first chunk of several. 4. The return value of sha256_ctx_mgr_submit() is nullptr at this point, since the hashing has been queued and is in progress. To make matters simple, I am using a synchronous flow with one context at the moment. So, in order to wait for synchronous compleition of the hash request, I call sha256_ctx_mgr_flush() on the context manager. This returns the pointer to my SHA_256_HASH_CTX object, whose error member indicates HASH_CTX_ERROR_NONE and whose status member indicates HASH_CTX_STS_IDLE. To me this indicates that the context manager is ready to cache the next chunk of the data using the hash context. 5. I continue to send in the remaining chunks just as in Step 3, except with the HASH_CTX_FLAG set to HASH_UPDATE for each subsequent chunk (except the last, which I will describe in the next step). After each submit, I await hashing completion using sha256_ctx_mgr_flush() which returns back my context. 6. I submit the last chunk as in step 3 except with the flag HASH_LAST. I then do a final sha256_ctx_mgr_flush() and look at the SHA256 hash data in the context's job.result_digest. This data gets reordered from big endian to little endian on each 32-bit word (e.g., 0x0a0b0c0d becomes 0x0d0c0b0a for each 32-bit word of the hash) and finally the hash is displayed in hex. This should produce a valid hash and in fact does as described below for the simple case of a single chunk. Important exception and notes: The hash is correct if I submit a single chunk with the flag HASH_ENTIRE, regardless of the size of the chunk. Unfortunately, if I break up the data and submit it in multiple chunks (HASH_FIRST, HASH_UPDATE..., HASH_LAST), using the methodology in the steps above, the hash produced is incorrect and in no way resembles the correct expected hash as indicated by for example the sha256sum utility. Please look at my steps above and tell me what I am doing wrong.

gbtucker commented

2018-08-15 00:30:31 -05:00

(Migrated from github.com)

From your steps described I don't see anything incorrect. If you look at the test sha256_mb_rand_update_test.c it does a similar thing by submitting buffers in pieces. Can you boil down into a small test case code?