sha256_var appears to produce different hash for each block #6163
Labels
bug
Something isn't working
Comments
5 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 2, 2024
# Description Fix an issue where `sha256_var` produces wrong results for messages with larger paddings ## Problem\* Resolves #6163 ## Summary\* `h = sha256_compression(msg_u8_to_u32(msg_block), h)` was run for bytes after length as well. This block is moved to `if msg_start < message_size` block ## Documentation\* Check one: - [ ] No documentation needed. - [ ] Documentation included in this PR. - [ ] **[For Experimental Features]** Documentation to be submitted in a separate PR. # PR Checklist\* - [ ] I have tested the changes locally. - [ ] I have formatted the changes with [Prettier](https://prettier.io/) and/or `cargo fmt` on default settings.
TomAFrench
added a commit
that referenced
this issue
Oct 7, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Aim
Tried to use sha256_var to produce a hash on a message padded by more than 64 bytes
Expected Behavior
std::hash::sha256::sha256_var() should produce the same hash for a (message: [u8; N], length: u64) regardless of N
Bug
each new sha256 block changes the hash value. it does not appear that the values set after the length have any effect on the outputted hash, just the max size of the inputted message array
To Reproduce
https://gist.github.com/jp4g/d5953faae9eadb2909357474f7901e58
Workaround
None
Workaround Description
No response
Additional Context
No response
Project Impact
Blocker
Blocker Context
No response
Nargo Version
0.34.0+359caafac5e489901d9ff02b08d1a688178d9b0a
NoirJS Version
No response
Proving Backend Tooling & Version
bb 0.55.0 (not used though)
Would you like to submit a PR for this Issue?
None
Support Needs
No response
The text was updated successfully, but these errors were encountered: