[gnutls-devel] GnuTLS | Unintended use of sizeof() on pointer (#1076)

Read-only notification of GnuTLS library development activities gnutls-devel at lists.gnutls.org
Sat Aug 29 09:13:27 CEST 2020




Daiki Ueno commented:


After digging it further, I'm in doubt with the `padlock_sha1_blocks` call itself. In the actual use of it in `sha-padlock.c` is the following:
```c
#define SHA1_COMPRESS(ctx, data) (padlock_sha1_blocks((void*)(ctx)->state, data, 1))

void
padlock_sha1_update(struct sha1_ctx *ctx,
		    size_t length, const uint8_t * data)
{
	MD_UPDATE(ctx, length, data, SHA1_COMPRESS, MD1_INCR(ctx));
}
```
where `MD_UPDATE` (defined in `<nettle/macros.h>`) takes a "compress" function as the 4th argument, which should have the following singature:
```c
void nettle_sha1_compress(uint32_t *state, const uint8_t *input);
```
which assumes that `input` contains a complete SHA-1 block (64 bytes).
Back to the `SHA1_COMPRESS` definition above, it calls `padlock_sha1_blocks` with the last argument 1. That indicates that, `padlock_sha1_blocks` takes the number of blocks rather than the number of characters.

Therefore, I conclude that the logic in `check_phe_partial` is completely wrong.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1076#note_404150382
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200829/22fb1de1/attachment-0001.html>


More information about the Gnutls-devel mailing list