More fixes and improvements #751

2026-04-30T02:39:58-05:00

sjaeckel commented

2026-04-30 02:39:58 -05:00

(Migrated from github.com)

Checklist

documentation is added or updated
tests are added or updated
if this fixes something: added a Fixes: tag to the commit message

### Checklist * [x] documentation is added or updated * [x] tests are added or updated * [x] if this fixes something: added a `Fixes:` tag to the commit message

karel-m (Migrated from github.com) reviewed

2026-04-30 13:15:16 -05:00

src/hashes/sha3.c

					
				@ -305,1 +308,4 @@

				      if(++sha3->word_index == (SHA3_KECCAK_SPONGE_WORDS - sha3->capacity_words)) {

				         proc_f(sha3->s);

				         sha3->word_index = 0;

				      }

what about also adding:

int sha3_shake128_init(hash_state *md)
{
   return s_sha3_shake_init(&md->sha3, 16);
}

int sha3_shake256_init(hash_state *md)
{
   return s_sha3_shake_init(&md->sha3, 32);
}

so that we can have:

const struct ltc_hash_descriptor shake128_desc = {..}

const struct ltc_hash_descriptor shake256_desc = {..}

which would be handy for RFC 8702: RSA-PSS-SHAKE128/256 and ECDSA-SHAKE128/256

what about also adding: ``` int sha3_shake128_init(hash_state *md) { return s_sha3_shake_init(&md->sha3, 16); } int sha3_shake256_init(hash_state *md) { return s_sha3_shake_init(&md->sha3, 32); } ``` so that we can have: ``` const struct ltc_hash_descriptor shake128_desc = {..} const struct ltc_hash_descriptor shake256_desc = {..} ``` which would be handy for RFC 8702: RSA-PSS-SHAKE128/256 and ECDSA-SHAKE128/256

karel-m commented

2026-05-03 04:57:01 -05:00

(Migrated from github.com)

I have added two small commits. Otherwise, this PR looks good.

The only exception is the LTC_NO_STRUCT_PADDING part, which I would suggest moving into a separate PR and perhars discuss pros/cons there. I have doubts whether it will work as expected, especially the change from ulong64 dummy[8] to void *padding[8]. In my opinion, this goes in the wrong direction as the reserved area becomes platform-dependent: 64 bytes vs. 32 bytes, depending on the pointer size.

I have added two small commits. Otherwise, this PR looks good. The only exception is the `LTC_NO_STRUCT_PADDING part`, which I would suggest moving into a separate PR and perhars discuss pros/cons there. I have doubts whether it will work as expected, especially the change from `ulong64 dummy[8]` to `void *padding[8]`. In my opinion, this goes in the wrong direction as the reserved area becomes platform-dependent: 64 bytes vs. 32 bytes, depending on the pointer size.

👍 1 ❤️ 1

karel-m commented

2026-05-03 15:21:51 -05:00

(Migrated from github.com)

The commit related to replacing LTC_FAST_TYPE_PTR_CAST might be seen as slightly controversial. If you find it inappropriate here feel free to revert it and/or move it to a separate PR.

The commit related to replacing `LTC_FAST_TYPE_PTR_CAST` might be seen as slightly controversial. If you find it inappropriate here feel free to revert it and/or move it to a separate PR.

karel-m commented

2026-05-03 16:23:54 -05:00

(Migrated from github.com)