Migrate to new padding rule

[Al-Kindi-0]

Describe your changes

Change the padding rule for RPO so that it uses the one in the xHash paper.

Checklist before requesting a review

• Repo forked and branch created from next according to naming convention.
• Commit messages and codestyle follow conventions.
• Relevant issues are linked in the PR description.
• Tests added for new functionality.
• Documentation/comments updated according to changes.

[bobbinth]

Looks good! Thank you! I left some comments inline - but all of them are pretty minor.

I was actually expecting a bit more changes - but nice to see that the impact is not that big.

[bobbinth]

Looks good! Thank you! I left a few more small comments inline.

Overall, let's hold off on merging this until we propagate the changes to miden-base (we can do that once we update miden-base to work with the current VM version).

[bobbinth]

All looks good! Thank you!

[bobbinth]

One thing that I realized: I'm not sure the behavior of this procedure is entirely consistent with its naming/docs. Specifically, we assume that the number of elements to be hashed is a multiple of 4 - so, for example, it cannot be used to hash 9 elements.

Maybe a better approach would be to split it into 2 procedures:

#! Input:  [C, B, A, start_addr, num_words, ...]
#! Output: [C', B', A', end_addr, ...]
export.absorb_words_from_memory

The above procedure would be similar to absorb_double_words_from_memory but would handle the case of the odd number of words. (separately, I think we could modify the absorb_double_words_from_memory procedure to also take num_words instead of end_addr).

The second procedure would actually be for computing hash of memory:

#! Input:  [start_addr, num_elements, ...]
#! Output: [HASH, end_addr, ...]
export.hash_memory

One open question is whether we should assume that the last word is padded with zeros (in case the number of elements is not divisible by 4) or if we need to handle this in the procedure.

[bobbinth]

@Fumuran - could you merge the latest next into this branch?

[bobbinth]

@Fumuran could you update this branch to use miden-crypto v0.11.0 (I just published it to crates.io) and also merge next into this branch to make sure we don't have any merge conflicts?

[bobbinth]

@Fumuran - this is basically done, right?

If so, before merging this, let's create a parallel PR in miden-base to migrate to the to this branch. I'm expecting that PR to be quite a bit of work because of the padding rule changes.

[Fumuran]

@bobbinth Should I prioritize migrating miden-base to the new padding rule over this issue (0xPolygonMiden/miden-base#836)?