Use little-endian encoding for Blake2 hashing on all architectures #38960
Conversation
| 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 |
|
⌛ Testing commit a89475d with merge e4fee52... |
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
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