bash-prg-hash: Initial implementation

[makavity]

1. I am not sure to assert in block_api
2. I am not sure in new and new_with_empty_header functions.

[makavity]

I am also not sure, it should be implemented as prg-hash.
Because AEAD algorithm uses start, squeeze, absorb and encrypt functions. But it is correct to implement encrypt here and make block_api methods - pub?

[newpavlov]

Sorry for the late review!

Some preliminary comments without looking deep at the implementation and the spec.

[makavity]

Thanks for review, @newpavlov.
As I see, all fixed

[makavity]

Looks like the sha1 is failed because timeout, not because PR changes.

[makavity]

I've commited it without squeeze from SpongeCursor, have no idea how to use it in current approach.

[newpavlov]

Should I left it as-as, or maybe another mode in SpongeCursor?

Can not say right now, I will need to read the spec first.

[newpavlov]

I refactored the code a fair bit. Feel free to comment on the changes if something is not clear or if you have suggestions on how we could improve it.

I think this PR is mostly ready for merge. We only need to release sponge-cursor and add tests for customized hashes.

[newpavlov]

This looks a bit weird, but I guess it's a consequence of mixing little-endian byte order and big-endian bit order in the spec and commit acting on the state outside of the rate part. For comparison, in cshake and turboshake we use self.state[RATE / 8 - 1] ^= 1 << 63;.

[makavity]

You're right, I suppose. I've noticed earlier, that spec is using first byte after rate.

[makavity]

I refactored the code a fair bit. Feel free to comment on the changes if something is not clear or if you have suggestions on how we could improve it.

Looks like the commit 1dc21053 broke the customization flow.
I'll commit the tests with announce, which worked before commit and continue to investigate.

[makavity]

Just misspell in the header length calculation.

[makavity]

@newpavlov in the methodic, there are test with 1000000 of 0x61 for input.
Should we add that tests for the completeness, or we can just skip it?

[makavity]

I refactored the code a fair bit. Feel free to comment on the changes if something is not clear or if you have suggestions on how we could improve it.

Really a fair bit. Now it's just two little functions :D
Awesome work, thank you!

[newpavlov]

there are test with 1000000 of 0x61 for input.

I think it's fine to add it (e.g. by feeding 1k byte chunks 1k times). It should be relatively fast.