Hi, On Mon, Nov 03, 2025 at 02:52:21PM +0200, Santtu Lakkala wrote: > On 26.10.2025 13.30, Hiltjo Posthuma wrote: > > > Maybe a starting point is in with processblock(): > > > > libutil/sha512.c: sha512_update() (defined in sha512-224.h). > > > > This is actually a simple case of passing wrongly sized buffer to > sha512_sum_n() when finalizing, and happens with any input. The problem lies
Ok, that makes sense. I suppose the buffer passes depends of the 'n' used in the specific hash. > with sha512_sum_n() requiring the digest length argument to be in multiples > of uint64_t, but for 224 bits this would be 3.5. Either the argument needs > to be changed to be more granular, or the sha512_224_sum() in > libutil/sha512-224.c needs to use a temporary buffer. uhmmmm, using an internal buffer can produce some problems in threaded programs. Maybe we can add a buffer to the ctxt parameter. Do you think the problem can be solved in that way? > The SHA-256 based sha224sum actually has the same problem, but there the fix > is simpler, just changing the argument of sha256_sum_n to 7, as SHA-256 > internally uses 32-bit ints. Sorry, I didn't understand this point. I don't see the relation between 7 and the internal 32-bit ints. Can you elaborate it a bit more? (take in account that I didn't write that code). Regards,
