Use little-endian encoding for Blake2 hashing on all architectures #38960
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| if cfg!(target_endian = "big") { | ||
| for word in &mut m[..] { | ||
| *word = word.to_be(); | ||
| *word = u64::from_le(*word); |
| let m: &mut [u64; 16] = unsafe { | ||
| let b: &mut [u8; 128] = &mut ctx.b; | ||
| ::std::mem::transmute(b) | ||
| }; | ||
|
|
||
| // It's OK to modify the buffer in place since this is the last time | ||
| // this data will be accessed before it's overwritten |
There was a problem hiding this comment.
Why remove this comment?
| // Re-interpret the input buffer in the state as u64s | ||
| // Re-interpret the input buffer in the state as | ||
| // an array of big-endian u64s, converting them | ||
| // to machine endianness. |
There was a problem hiding this comment.
Isn't it the other way round: We always make sure that this buffer is little-endian and now we are making sure to convert it to machine endianess?
|
Fixed nits.
Blake2b is a standard bytestream hasher. It should not do anything weird with its Hasher impl. @bors r=michaelwoerister |
|
📌 Commit bccd756 has been approved by |
arielb1
added
the
beta-nominated
arielb1
changed the title
Like many hash functions, the blake2 hash is mathematically defined on a sequence of 64-bit words. As Rust's hash interface operates on sequences of octets, some encoding must be used to bridge that difference. The Blake2 RFC (RFC 7693) specifies that: Byte (octet) streams are interpreted as words in little-endian order, with the least-significant byte first. So use that encoding consistently. Fixes rust-lang#38891.
|
@bors r=michaelwoerister |
|
📌 Commit a89475d has been approved by |
|
@bors rollup |
|
@bors rollup- |
|
@bors p=1
|
nikomatsakis
added
the
beta-accepted
|
Accepting for beta. Small patch, regression. cc @rust-lang/compiler |
bors
added a commit
that referenced
this pull request
Jan 11, 2017
Use little-endian encoding for Blake2 hashing on all architectures Like many hash functions, the blake2 hash is mathematically defined on a sequence of 64-bit words. As Rust's hash interface operates on sequences of octets, some encoding must be used to bridge that difference. The Blake2 RFC (RFC 7693) specifies that: ``` Byte (octet) streams are interpreted as words in little-endian order, with the least-significant byte first. ``` So use that encoding consistently. Fixes #38891. Beta-nominating since this is a regression since 1.15. r? @michaelwoerister
|
☀️ Test successful - status-appveyor, status-travis |
alexcrichton
removed
the
beta-nominated
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Like many hash functions, the blake2 hash is mathematically defined on
a sequence of 64-bit words. As Rust's hash interface operates on
sequences of octets, some encoding must be used to bridge that
difference.
The Blake2 RFC (RFC 7693) specifies that:
So use that encoding consistently.
Fixes #38891.
Beta-nominating since this is a regression since 1.15.
r? @michaelwoerister