milksad
/
rust-bitcoin-unsafe-fast
14
0
Fork 0
Code Issues Pull Requests Activity
rust-bitcoin-unsafe-fast/hashes/src/ripemd160.rs

566 lines
25 KiB
Rust
Raw Normal View History

hashes: Introduce SPDX license identifiers Whether or not every file needs an explicit license comment is out of scope for this patch; in the `bitcoin` crate we use SPDX identifiers because they are a single line with no loss of "benefit" over any longer form. Use SPDX identifiers in `hashes`. Drop the mention of re-licensing code from Apache to CC0-1 (because the original code was written by Andrew as well as the copied code then if the argument ever comes up it can be easily countered).
2023-04-30 23:26:36 +00:00
// SPDX-License-Identifier: CC0-1.0
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
//! RIPEMD160 implementation.
//!
use core::convert::TryInto;
use core::ops::Index;
use core::slice::SliceIndex;
hashes: Run the formatter Run `cargo +nightly fmt`, no other manual changes.
2023-02-21 23:25:12 +00:00
use core::{cmp, str};
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
Improve hashes::Error We are trying to make error types stable on the way to v1.0 The current `hashes::Error` is a "general" enum error type with a single variant, better to use a struct and make the error usecase specific. Improve the `hashes::Error` by doing: - Make it a struct - Rename to `FromSliceError` - Move it to the crate root (remove `error` module) Includes usage in `bitcoin`.
2023-05-24 03:29:30 +00:00
use crate::{FromSliceError, HashEngine as _};
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
crate::internal_macros::hash_type! {
160,
false,
"Output of the RIPEMD160 hash function.",
"crate::util::json_hex_string::len_20"
}
hashes: rename fuzzing cfg parameter to bitcoin_hashes_fuzz
2023-04-28 18:44:54 +00:00
#[cfg(not(hashes_fuzz))]
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
fn from_engine(mut e: HashEngine) -> Hash {
// pad buffer with a single 1-bit then all 0s, until there are exactly 8 bytes remaining
let data_len = e.length as u64;
let zeroes = [0; BLOCK_SIZE - 8];
e.input(&[0x80]);
if e.length % BLOCK_SIZE > zeroes.len() {
e.input(&zeroes);
}
let pad_length = zeroes.len() - (e.length % BLOCK_SIZE);
e.input(&zeroes[..pad_length]);
debug_assert_eq!(e.length % BLOCK_SIZE, zeroes.len());
e.input(&(8 * data_len).to_le_bytes());
debug_assert_eq!(e.length % BLOCK_SIZE, 0);
Hash(e.midstate())
}
hashes: rename fuzzing cfg parameter to bitcoin_hashes_fuzz
2023-04-28 18:44:54 +00:00
#[cfg(hashes_fuzz)]
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
fn from_engine(e: HashEngine) -> Hash {
let mut res = e.midstate();
res[0] ^= (e.length & 0xff) as u8;
Hash(res)
}
const BLOCK_SIZE: usize = 64;
/// Engine to compute RIPEMD160 hash function.
#[derive(Clone)]
pub struct HashEngine {
buffer: [u8; BLOCK_SIZE],
h: [u32; 5],
length: usize,
}
impl Default for HashEngine {
fn default() -> Self {
HashEngine {
h: [0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476, 0xc3d2e1f0],
length: 0,
buffer: [0; BLOCK_SIZE],
}
}
}
impl crate::HashEngine for HashEngine {
type MidState = [u8; 20];
hashes: rename fuzzing cfg parameter to bitcoin_hashes_fuzz
2023-04-28 18:44:54 +00:00
#[cfg(not(hashes_fuzz))]
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
fn midstate(&self) -> [u8; 20] {
let mut ret = [0; 20];
for (val, ret_bytes) in self.h.iter().zip(ret.chunks_exact_mut(4)) {
ret_bytes.copy_from_slice(&(*val).to_le_bytes());
}
ret
}
hashes: rename fuzzing cfg parameter to bitcoin_hashes_fuzz
2023-04-28 18:44:54 +00:00
#[cfg(hashes_fuzz)]
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
fn midstate(&self) -> [u8; 20] {
let mut ret = [0; 20];
ret.copy_from_slice(&self.buffer[..20]);
ret
}
const BLOCK_SIZE: usize = 64;
hashes: Run the formatter Run `cargo +nightly fmt`, no other manual changes.
2023-02-21 23:25:12 +00:00
fn n_bytes_hashed(&self) -> usize { self.length }
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
engine_input_impl!();
}
Introduce the `small-hash` feature for `bitcoin_hashes` When enabled this feature swaps the hash implementation of sha512, sha256 and ripemd160 for a smaller (but also slower) one. On embedded processors (Cortex-M4) it can lead to up to a 52% size reduction, from around 37KiB for just the `process_block` methods of the three hash functions to 17.8KiB.
2023-08-11 19:31:20 +00:00
#[cfg(feature = "small-hash")]
#[macro_use]
mod small_hash {
#[rustfmt::skip]
pub(super) fn round(a: u32, _b: u32, c: u32, _d: u32, e: u32,
x: u32, bits: u32, add: u32, round: u32,
) -> (u32, u32) {
let a = a.wrapping_add(round).wrapping_add(x).wrapping_add(add);
let a = a.rotate_left(bits).wrapping_add(e);
let c = c.rotate_left(10);
(a, c)
}
macro_rules! round(
($a:expr, $b:expr, $c:expr, $d:expr, $e:expr,
$x:expr, $bits:expr, $add:expr, $round:expr) => ({
let updates = small_hash::round($a, $b, $c, $d, $e, $x, $bits, $add, $round);
$a = updates.0;
$c = updates.1;
});
);
}
#[cfg(not(feature = "small-hash"))]
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
macro_rules! round(
($a:expr, $b:expr, $c:expr, $d:expr, $e:expr,
$x:expr, $bits:expr, $add:expr, $round:expr) => ({
$a = $a.wrapping_add($round).wrapping_add($x).wrapping_add($add);
$a = $a.rotate_left($bits).wrapping_add($e);
$c = $c.rotate_left(10);
});
);
macro_rules! process_block(
($h:expr, $data:expr,
$( round1: h_ordering $f0:expr, $f1:expr, $f2:expr, $f3:expr, $f4:expr;
data_index $data_index1:expr; roll_shift $bits1:expr; )*
$( round2: h_ordering $g0:expr, $g1:expr, $g2:expr, $g3:expr, $g4:expr;
data_index $data_index2:expr; roll_shift $bits2:expr; )*
$( round3: h_ordering $h0:expr, $h1:expr, $h2:expr, $h3:expr, $h4:expr;
data_index $data_index3:expr; roll_shift $bits3:expr; )*
$( round4: h_ordering $i0:expr, $i1:expr, $i2:expr, $i3:expr, $i4:expr;
data_index $data_index4:expr; roll_shift $bits4:expr; )*
$( round5: h_ordering $j0:expr, $j1:expr, $j2:expr, $j3:expr, $j4:expr;
data_index $data_index5:expr; roll_shift $bits5:expr; )*
$( par_round1: h_ordering $pj0:expr, $pj1:expr, $pj2:expr, $pj3:expr, $pj4:expr;
data_index $pdata_index1:expr; roll_shift $pbits1:expr; )*
$( par_round2: h_ordering $pi0:expr, $pi1:expr, $pi2:expr, $pi3:expr, $pi4:expr;
data_index $pdata_index2:expr; roll_shift $pbits2:expr; )*
$( par_round3: h_ordering $ph0:expr, $ph1:expr, $ph2:expr, $ph3:expr, $ph4:expr;
data_index $pdata_index3:expr; roll_shift $pbits3:expr; )*
$( par_round4: h_ordering $pg0:expr, $pg1:expr, $pg2:expr, $pg3:expr, $pg4:expr;
data_index $pdata_index4:expr; roll_shift $pbits4:expr; )*
$( par_round5: h_ordering $pf0:expr, $pf1:expr, $pf2:expr, $pf3:expr, $pf4:expr;
data_index $pdata_index5:expr; roll_shift $pbits5:expr; )*
) => ({
let mut bb = $h;
let mut bbb = $h;
// Round 1
$( round!(bb[$f0], bb[$f1], bb[$f2], bb[$f3], bb[$f4],
$data[$data_index1], $bits1, 0x00000000,
bb[$f1] ^ bb[$f2] ^ bb[$f3]); )*
// Round 2
$( round!(bb[$g0], bb[$g1], bb[$g2], bb[$g3], bb[$g4],
$data[$data_index2], $bits2, 0x5a827999,
(bb[$g1] & bb[$g2]) | (!bb[$g1] & bb[$g3])); )*
// Round 3
$( round!(bb[$h0], bb[$h1], bb[$h2], bb[$h3], bb[$h4],
$data[$data_index3], $bits3, 0x6ed9eba1,
(bb[$h1] | !bb[$h2]) ^ bb[$h3]); )*
// Round 4
$( round!(bb[$i0], bb[$i1], bb[$i2], bb[$i3], bb[$i4],
$data[$data_index4], $bits4, 0x8f1bbcdc,
(bb[$i1] & bb[$i3]) | (bb[$i2] & !bb[$i3])); )*
// Round 5
$( round!(bb[$j0], bb[$j1], bb[$j2], bb[$j3], bb[$j4],
$data[$data_index5], $bits5, 0xa953fd4e,
bb[$j1] ^ (bb[$j2] | !bb[$j3])); )*
// Parallel rounds: these are the same as the previous five
// rounds except that the constants have changed, we work
// with the other buffer, and they are applied in reverse
// order.
// Parallel Round 1
$( round!(bbb[$pj0], bbb[$pj1], bbb[$pj2], bbb[$pj3], bbb[$pj4],
$data[$pdata_index1], $pbits1, 0x50a28be6,
bbb[$pj1] ^ (bbb[$pj2] | !bbb[$pj3])); )*
// Porallel Round 2
$( round!(bbb[$pi0], bbb[$pi1], bbb[$pi2], bbb[$pi3], bbb[$pi4],
$data[$pdata_index2], $pbits2, 0x5c4dd124,
(bbb[$pi1] & bbb[$pi3]) | (bbb[$pi2] & !bbb[$pi3])); )*
// Parallel Round 3
$( round!(bbb[$ph0], bbb[$ph1], bbb[$ph2], bbb[$ph3], bbb[$ph4],
$data[$pdata_index3], $pbits3, 0x6d703ef3,
(bbb[$ph1] | !bbb[$ph2]) ^ bbb[$ph3]); )*
// Parallel Round 4
$( round!(bbb[$pg0], bbb[$pg1], bbb[$pg2], bbb[$pg3], bbb[$pg4],
$data[$pdata_index4], $pbits4, 0x7a6d76e9,
(bbb[$pg1] & bbb[$pg2]) | (!bbb[$pg1] & bbb[$pg3])); )*
// Parallel Round 5
$( round!(bbb[$pf0], bbb[$pf1], bbb[$pf2], bbb[$pf3], bbb[$pf4],
$data[$pdata_index5], $pbits5, 0x00000000,
bbb[$pf1] ^ bbb[$pf2] ^ bbb[$pf3]); )*
// Combine results
bbb[3] = bbb[3].wrapping_add($h[1]).wrapping_add(bb[2]);
$h[1] = $h[2].wrapping_add(bb[3]).wrapping_add(bbb[4]);
$h[2] = $h[3].wrapping_add(bb[4]).wrapping_add(bbb[0]);
$h[3] = $h[4].wrapping_add(bb[0]).wrapping_add(bbb[1]);
$h[4] = $h[0].wrapping_add(bb[1]).wrapping_add(bbb[2]);
$h[0] = bbb[3];
});
);
impl HashEngine {
fn process_block(&mut self) {
debug_assert_eq!(self.buffer.len(), BLOCK_SIZE);
let mut w = [0u32; 16];
for (w_val, buff_bytes) in w.iter_mut().zip(self.buffer.chunks_exact(4)) {
*w_val = u32::from_le_bytes(buff_bytes.try_into().expect("4 byte slice"))
}
process_block!(self.h, w,
// Round 1
round1: h_ordering 0, 1, 2, 3, 4; data_index 0; roll_shift 11;
round1: h_ordering 4, 0, 1, 2, 3; data_index 1; roll_shift 14;
round1: h_ordering 3, 4, 0, 1, 2; data_index 2; roll_shift 15;
round1: h_ordering 2, 3, 4, 0, 1; data_index 3; roll_shift 12;
round1: h_ordering 1, 2, 3, 4, 0; data_index 4; roll_shift 5;
round1: h_ordering 0, 1, 2, 3, 4; data_index 5; roll_shift 8;
round1: h_ordering 4, 0, 1, 2, 3; data_index 6; roll_shift 7;
round1: h_ordering 3, 4, 0, 1, 2; data_index 7; roll_shift 9;
round1: h_ordering 2, 3, 4, 0, 1; data_index 8; roll_shift 11;
round1: h_ordering 1, 2, 3, 4, 0; data_index 9; roll_shift 13;
round1: h_ordering 0, 1, 2, 3, 4; data_index 10; roll_shift 14;
round1: h_ordering 4, 0, 1, 2, 3; data_index 11; roll_shift 15;
round1: h_ordering 3, 4, 0, 1, 2; data_index 12; roll_shift 6;
round1: h_ordering 2, 3, 4, 0, 1; data_index 13; roll_shift 7;
round1: h_ordering 1, 2, 3, 4, 0; data_index 14; roll_shift 9;
round1: h_ordering 0, 1, 2, 3, 4; data_index 15; roll_shift 8;
// Round 2
round2: h_ordering 4, 0, 1, 2, 3; data_index 7; roll_shift 7;
round2: h_ordering 3, 4, 0, 1, 2; data_index 4; roll_shift 6;
round2: h_ordering 2, 3, 4, 0, 1; data_index 13; roll_shift 8;
round2: h_ordering 1, 2, 3, 4, 0; data_index 1; roll_shift 13;
round2: h_ordering 0, 1, 2, 3, 4; data_index 10; roll_shift 11;
round2: h_ordering 4, 0, 1, 2, 3; data_index 6; roll_shift 9;
round2: h_ordering 3, 4, 0, 1, 2; data_index 15; roll_shift 7;
round2: h_ordering 2, 3, 4, 0, 1; data_index 3; roll_shift 15;
round2: h_ordering 1, 2, 3, 4, 0; data_index 12; roll_shift 7;
round2: h_ordering 0, 1, 2, 3, 4; data_index 0; roll_shift 12;
round2: h_ordering 4, 0, 1, 2, 3; data_index 9; roll_shift 15;
round2: h_ordering 3, 4, 0, 1, 2; data_index 5; roll_shift 9;
round2: h_ordering 2, 3, 4, 0, 1; data_index 2; roll_shift 11;
round2: h_ordering 1, 2, 3, 4, 0; data_index 14; roll_shift 7;
round2: h_ordering 0, 1, 2, 3, 4; data_index 11; roll_shift 13;
round2: h_ordering 4, 0, 1, 2, 3; data_index 8; roll_shift 12;
// Round 3
round3: h_ordering 3, 4, 0, 1, 2; data_index 3; roll_shift 11;
round3: h_ordering 2, 3, 4, 0, 1; data_index 10; roll_shift 13;
round3: h_ordering 1, 2, 3, 4, 0; data_index 14; roll_shift 6;
round3: h_ordering 0, 1, 2, 3, 4; data_index 4; roll_shift 7;
round3: h_ordering 4, 0, 1, 2, 3; data_index 9; roll_shift 14;
round3: h_ordering 3, 4, 0, 1, 2; data_index 15; roll_shift 9;
round3: h_ordering 2, 3, 4, 0, 1; data_index 8; roll_shift 13;
round3: h_ordering 1, 2, 3, 4, 0; data_index 1; roll_shift 15;
round3: h_ordering 0, 1, 2, 3, 4; data_index 2; roll_shift 14;
round3: h_ordering 4, 0, 1, 2, 3; data_index 7; roll_shift 8;
round3: h_ordering 3, 4, 0, 1, 2; data_index 0; roll_shift 13;
round3: h_ordering 2, 3, 4, 0, 1; data_index 6; roll_shift 6;
round3: h_ordering 1, 2, 3, 4, 0; data_index 13; roll_shift 5;
round3: h_ordering 0, 1, 2, 3, 4; data_index 11; roll_shift 12;
round3: h_ordering 4, 0, 1, 2, 3; data_index 5; roll_shift 7;
round3: h_ordering 3, 4, 0, 1, 2; data_index 12; roll_shift 5;
// Round 4
round4: h_ordering 2, 3, 4, 0, 1; data_index 1; roll_shift 11;
round4: h_ordering 1, 2, 3, 4, 0; data_index 9; roll_shift 12;
round4: h_ordering 0, 1, 2, 3, 4; data_index 11; roll_shift 14;
round4: h_ordering 4, 0, 1, 2, 3; data_index 10; roll_shift 15;
round4: h_ordering 3, 4, 0, 1, 2; data_index 0; roll_shift 14;
round4: h_ordering 2, 3, 4, 0, 1; data_index 8; roll_shift 15;
round4: h_ordering 1, 2, 3, 4, 0; data_index 12; roll_shift 9;
round4: h_ordering 0, 1, 2, 3, 4; data_index 4; roll_shift 8;
round4: h_ordering 4, 0, 1, 2, 3; data_index 13; roll_shift 9;
round4: h_ordering 3, 4, 0, 1, 2; data_index 3; roll_shift 14;
round4: h_ordering 2, 3, 4, 0, 1; data_index 7; roll_shift 5;
round4: h_ordering 1, 2, 3, 4, 0; data_index 15; roll_shift 6;
round4: h_ordering 0, 1, 2, 3, 4; data_index 14; roll_shift 8;
round4: h_ordering 4, 0, 1, 2, 3; data_index 5; roll_shift 6;
round4: h_ordering 3, 4, 0, 1, 2; data_index 6; roll_shift 5;
round4: h_ordering 2, 3, 4, 0, 1; data_index 2; roll_shift 12;
// Round 5
round5: h_ordering 1, 2, 3, 4, 0; data_index 4; roll_shift 9;
round5: h_ordering 0, 1, 2, 3, 4; data_index 0; roll_shift 15;
round5: h_ordering 4, 0, 1, 2, 3; data_index 5; roll_shift 5;
round5: h_ordering 3, 4, 0, 1, 2; data_index 9; roll_shift 11;
round5: h_ordering 2, 3, 4, 0, 1; data_index 7; roll_shift 6;
round5: h_ordering 1, 2, 3, 4, 0; data_index 12; roll_shift 8;
round5: h_ordering 0, 1, 2, 3, 4; data_index 2; roll_shift 13;
round5: h_ordering 4, 0, 1, 2, 3; data_index 10; roll_shift 12;
round5: h_ordering 3, 4, 0, 1, 2; data_index 14; roll_shift 5;
round5: h_ordering 2, 3, 4, 0, 1; data_index 1; roll_shift 12;
round5: h_ordering 1, 2, 3, 4, 0; data_index 3; roll_shift 13;
round5: h_ordering 0, 1, 2, 3, 4; data_index 8; roll_shift 14;
round5: h_ordering 4, 0, 1, 2, 3; data_index 11; roll_shift 11;
round5: h_ordering 3, 4, 0, 1, 2; data_index 6; roll_shift 8;
round5: h_ordering 2, 3, 4, 0, 1; data_index 15; roll_shift 5;
round5: h_ordering 1, 2, 3, 4, 0; data_index 13; roll_shift 6;
// Porallel Round 1;
par_round1: h_ordering 0, 1, 2, 3, 4; data_index 5; roll_shift 8;
par_round1: h_ordering 4, 0, 1, 2, 3; data_index 14; roll_shift 9;
par_round1: h_ordering 3, 4, 0, 1, 2; data_index 7; roll_shift 9;
par_round1: h_ordering 2, 3, 4, 0, 1; data_index 0; roll_shift 11;
par_round1: h_ordering 1, 2, 3, 4, 0; data_index 9; roll_shift 13;
par_round1: h_ordering 0, 1, 2, 3, 4; data_index 2; roll_shift 15;
par_round1: h_ordering 4, 0, 1, 2, 3; data_index 11; roll_shift 15;
par_round1: h_ordering 3, 4, 0, 1, 2; data_index 4; roll_shift 5;
par_round1: h_ordering 2, 3, 4, 0, 1; data_index 13; roll_shift 7;
par_round1: h_ordering 1, 2, 3, 4, 0; data_index 6; roll_shift 7;
par_round1: h_ordering 0, 1, 2, 3, 4; data_index 15; roll_shift 8;
par_round1: h_ordering 4, 0, 1, 2, 3; data_index 8; roll_shift 11;
par_round1: h_ordering 3, 4, 0, 1, 2; data_index 1; roll_shift 14;
par_round1: h_ordering 2, 3, 4, 0, 1; data_index 10; roll_shift 14;
par_round1: h_ordering 1, 2, 3, 4, 0; data_index 3; roll_shift 12;
par_round1: h_ordering 0, 1, 2, 3, 4; data_index 12; roll_shift 6;
// Parallel Round 2
par_round2: h_ordering 4, 0, 1, 2, 3; data_index 6; roll_shift 9;
par_round2: h_ordering 3, 4, 0, 1, 2; data_index 11; roll_shift 13;
par_round2: h_ordering 2, 3, 4, 0, 1; data_index 3; roll_shift 15;
par_round2: h_ordering 1, 2, 3, 4, 0; data_index 7; roll_shift 7;
par_round2: h_ordering 0, 1, 2, 3, 4; data_index 0; roll_shift 12;
par_round2: h_ordering 4, 0, 1, 2, 3; data_index 13; roll_shift 8;
par_round2: h_ordering 3, 4, 0, 1, 2; data_index 5; roll_shift 9;
par_round2: h_ordering 2, 3, 4, 0, 1; data_index 10; roll_shift 11;
par_round2: h_ordering 1, 2, 3, 4, 0; data_index 14; roll_shift 7;
par_round2: h_ordering 0, 1, 2, 3, 4; data_index 15; roll_shift 7;
par_round2: h_ordering 4, 0, 1, 2, 3; data_index 8; roll_shift 12;
par_round2: h_ordering 3, 4, 0, 1, 2; data_index 12; roll_shift 7;
par_round2: h_ordering 2, 3, 4, 0, 1; data_index 4; roll_shift 6;
par_round2: h_ordering 1, 2, 3, 4, 0; data_index 9; roll_shift 15;
par_round2: h_ordering 0, 1, 2, 3, 4; data_index 1; roll_shift 13;
par_round2: h_ordering 4, 0, 1, 2, 3; data_index 2; roll_shift 11;
// Parallel Round 3
par_round3: h_ordering 3, 4, 0, 1, 2; data_index 15; roll_shift 9;
par_round3: h_ordering 2, 3, 4, 0, 1; data_index 5; roll_shift 7;
par_round3: h_ordering 1, 2, 3, 4, 0; data_index 1; roll_shift 15;
par_round3: h_ordering 0, 1, 2, 3, 4; data_index 3; roll_shift 11;
par_round3: h_ordering 4, 0, 1, 2, 3; data_index 7; roll_shift 8;
par_round3: h_ordering 3, 4, 0, 1, 2; data_index 14; roll_shift 6;
par_round3: h_ordering 2, 3, 4, 0, 1; data_index 6; roll_shift 6;
par_round3: h_ordering 1, 2, 3, 4, 0; data_index 9; roll_shift 14;
par_round3: h_ordering 0, 1, 2, 3, 4; data_index 11; roll_shift 12;
par_round3: h_ordering 4, 0, 1, 2, 3; data_index 8; roll_shift 13;
par_round3: h_ordering 3, 4, 0, 1, 2; data_index 12; roll_shift 5;
par_round3: h_ordering 2, 3, 4, 0, 1; data_index 2; roll_shift 14;
par_round3: h_ordering 1, 2, 3, 4, 0; data_index 10; roll_shift 13;
par_round3: h_ordering 0, 1, 2, 3, 4; data_index 0; roll_shift 13;
par_round3: h_ordering 4, 0, 1, 2, 3; data_index 4; roll_shift 7;
par_round3: h_ordering 3, 4, 0, 1, 2; data_index 13; roll_shift 5;
// Parallel Round 4
par_round4: h_ordering 2, 3, 4, 0, 1; data_index 8; roll_shift 15;
par_round4: h_ordering 1, 2, 3, 4, 0; data_index 6; roll_shift 5;
par_round4: h_ordering 0, 1, 2, 3, 4; data_index 4; roll_shift 8;
par_round4: h_ordering 4, 0, 1, 2, 3; data_index 1; roll_shift 11;
par_round4: h_ordering 3, 4, 0, 1, 2; data_index 3; roll_shift 14;
par_round4: h_ordering 2, 3, 4, 0, 1; data_index 11; roll_shift 14;
par_round4: h_ordering 1, 2, 3, 4, 0; data_index 15; roll_shift 6;
par_round4: h_ordering 0, 1, 2, 3, 4; data_index 0; roll_shift 14;
par_round4: h_ordering 4, 0, 1, 2, 3; data_index 5; roll_shift 6;
par_round4: h_ordering 3, 4, 0, 1, 2; data_index 12; roll_shift 9;
par_round4: h_ordering 2, 3, 4, 0, 1; data_index 2; roll_shift 12;
par_round4: h_ordering 1, 2, 3, 4, 0; data_index 13; roll_shift 9;
par_round4: h_ordering 0, 1, 2, 3, 4; data_index 9; roll_shift 12;
par_round4: h_ordering 4, 0, 1, 2, 3; data_index 7; roll_shift 5;
par_round4: h_ordering 3, 4, 0, 1, 2; data_index 10; roll_shift 15;
par_round4: h_ordering 2, 3, 4, 0, 1; data_index 14; roll_shift 8;
// Parallel Round 5
par_round5: h_ordering 1, 2, 3, 4, 0; data_index 12; roll_shift 8;
par_round5: h_ordering 0, 1, 2, 3, 4; data_index 15; roll_shift 5;
par_round5: h_ordering 4, 0, 1, 2, 3; data_index 10; roll_shift 12;
par_round5: h_ordering 3, 4, 0, 1, 2; data_index 4; roll_shift 9;
par_round5: h_ordering 2, 3, 4, 0, 1; data_index 1; roll_shift 12;
par_round5: h_ordering 1, 2, 3, 4, 0; data_index 5; roll_shift 5;
par_round5: h_ordering 0, 1, 2, 3, 4; data_index 8; roll_shift 14;
par_round5: h_ordering 4, 0, 1, 2, 3; data_index 7; roll_shift 6;
par_round5: h_ordering 3, 4, 0, 1, 2; data_index 6; roll_shift 8;
par_round5: h_ordering 2, 3, 4, 0, 1; data_index 2; roll_shift 13;
par_round5: h_ordering 1, 2, 3, 4, 0; data_index 13; roll_shift 6;
par_round5: h_ordering 0, 1, 2, 3, 4; data_index 14; roll_shift 5;
par_round5: h_ordering 4, 0, 1, 2, 3; data_index 0; roll_shift 15;
par_round5: h_ordering 3, 4, 0, 1, 2; data_index 3; roll_shift 13;
par_round5: h_ordering 2, 3, 4, 0, 1; data_index 9; roll_shift 11;
par_round5: h_ordering 1, 2, 3, 4, 0; data_index 11; roll_shift 11;
);
}
}
#[cfg(test)]
mod tests {
#[test]
hashes: Improve feature gating Currently we have a few things mixed up in the feature gating of `hashes`. Observe that: - `io::Write` is not related to allocation. - "std" should be able to enable "alloc". Improve feature gating by doing: - Enable "alloc" from "std" and simplify `cfg` codebase wide. - Enable "internals/alloc" from "alloc". - Fix feature gating to use the minimal requirement i.e., "alloc".
2023-01-21 03:43:48 +00:00
#[cfg(feature = "alloc")]
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
fn test() {
Feature (hashes): Add from_bytes_ref and from_bytes_mut to all Hash types
2023-03-29 01:27:41 +00:00
use std::convert::TryFrom;
hashes: Run the formatter Run `cargo +nightly fmt`, no other manual changes.
2023-02-21 23:25:12 +00:00
use crate::{ripemd160, Hash, HashEngine};
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
#[derive(Clone)]
struct Test {
input: &'static str,
output: Vec<u8>,
output_str: &'static str,
}
Enable formatting for hashes The `hashes` module contains a bunch of arrays, mostly formatted with 8 hex bytes on a line; add `rustfmt::skip` to keep the formatting of arrays as is. Remove the exclude for the `hashes` crate. Do not run the formatter, that will be done as a separate patch to aid review.
2023-02-21 23:04:08 +00:00
#[rustfmt::skip]
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
let tests = vec![
// Test messages from FIPS 180-1
Test {
input: "abc",
output: vec![
0x8e, 0xb2, 0x08, 0xf7,
0xe0, 0x5d, 0x98, 0x7a,
0x9b, 0x04, 0x4a, 0x8e,
0x98, 0xc6, 0xb0, 0x87,
0xf1, 0x5a, 0x0b, 0xfc,
],
output_str: "8eb208f7e05d987a9b044a8e98c6b087f15a0bfc"
},
Test {
input:
"abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq",
output: vec![
0x12, 0xa0, 0x53, 0x38,
0x4a, 0x9c, 0x0c, 0x88,
0xe4, 0x05, 0xa0, 0x6c,
0x27, 0xdc, 0xf4, 0x9a,
0xda, 0x62, 0xeb, 0x2b,
],
output_str: "12a053384a9c0c88e405a06c27dcf49ada62eb2b"
},
// Examples from wikipedia
Test {
input: "The quick brown fox jumps over the lazy dog",
output: vec![
0x37, 0xf3, 0x32, 0xf6,
0x8d, 0xb7, 0x7b, 0xd9,
0xd7, 0xed, 0xd4, 0x96,
0x95, 0x71, 0xad, 0x67,
0x1c, 0xf9, 0xdd, 0x3b,
],
output_str: "37f332f68db77bd9d7edd4969571ad671cf9dd3b",
},
Test {
input: "The quick brown fox jumps over the lazy cog",
output: vec![
0x13, 0x20, 0x72, 0xdf,
0x69, 0x09, 0x33, 0x83,
0x5e, 0xb8, 0xb6, 0xad,
0x0b, 0x77, 0xe7, 0xb6,
0xf1, 0x4a, 0xca, 0xd7,
],
output_str: "132072df690933835eb8b6ad0b77e7b6f14acad7",
},
];
Feature (hashes): Add from_bytes_ref and from_bytes_mut to all Hash types
2023-03-29 01:27:41 +00:00
for mut test in tests {
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
// Hash through high-level API, check hex encoding/decoding
Fix new clippy warnings
2022-12-01 23:59:08 +00:00
let hash = ripemd160::Hash::hash(test.input.as_bytes());
Remove FromHex for all types except Vec and array Remove `FromHex` from hash and script types - Remove the `FromHex` implementation from hash types and `ScriptBuf` - Remove the `FromStr` implementation from `ScriptBuf` because it does not roundtrip with `Display`. - Implement a method `from_hex` on `ScriptBuf`. - Implement `FromStr` on hash types using a fixed size array. This leaves `FromHex` implementations only on `Vec` and fixed size arrays.
2023-01-20 00:24:48 +00:00
assert_eq!(hash, test.output_str.parse::<ripemd160::Hash>().expect("parse hex"));
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
assert_eq!(&hash[..], &test.output[..]);
Remove `ToHex` The `ToHex` trait was replaced by either simple `Display`/`LowerHex` where appropriate or `DisplayHex` from `bitcoin_internals` which is faster. This change replaces the usages and removes the trait.
2023-01-07 15:39:11 +00:00
assert_eq!(&hash.to_string(), &test.output_str);
Feature (hashes): Add from_bytes_ref and from_bytes_mut to all Hash types
2023-03-29 01:27:41 +00:00
assert_eq!(
ripemd160::Hash::from_bytes_ref(
<&[u8; 20]>::try_from(&*test.output).expect("known length")
),
&hash
);
assert_eq!(
ripemd160::Hash::from_bytes_mut(
<&mut [u8; 20]>::try_from(&mut *test.output).expect("known length")
),
&hash
);
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
// Hash through engine, checking that we can input byte by byte
let mut engine = ripemd160::Hash::engine();
for ch in test.input.as_bytes() {
engine.input(&[*ch]);
}
let manual_hash = ripemd160::Hash::from_engine(engine);
assert_eq!(hash, manual_hash);
Re-name hash inner/byte methods Currently we have an associated type on hash types `Inner` with accompanying methods `into_inner`, `from_inner`, `as_inner`. Also, we provide a way to create new wrapped hash types. The use of 'inner' becomes ambiguous with the addition of wrapped types because the inner could be the inner hash type or the `Inner` byte array of the inner wrapped hash type. In an effort to make the API more clear and uniform do the following: - Rename `Inner` -> `Bytes` - Rename `*_inner` -> `*_byte_array` - Rename the inner hash to/from methods to `*_raw_hash` Correct method prefix `into_` -> `to_` because theses methods convert owned `Copy` types. Add the trait Bound `Copy` to the `Bytes` type because we rely on this trait bound for the conversion methods to be correctly named according to convention. Because of the dependency hole created by `secp256k1` this patch changes the secp dependency to a git tag dependency that includes changes to the hashes calls required so that we can get green lights on CI in this repo.
2023-01-28 22:47:24 +00:00
assert_eq!(hash.as_byte_array(), test.output.as_slice());
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
}
}
#[cfg(feature = "serde")]
#[test]
fn ripemd_serde() {
hashes: Run the formatter Run `cargo +nightly fmt`, no other manual changes.
2023-02-21 23:25:12 +00:00
use serde_test::{assert_tokens, Configure, Token};
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
use crate::{ripemd160, Hash};
Enable formatting for hashes The `hashes` module contains a bunch of arrays, mostly formatted with 8 hex bytes on a line; add `rustfmt::skip` to keep the formatting of arrays as is. Remove the exclude for the `hashes` crate. Do not run the formatter, that will be done as a separate patch to aid review.
2023-02-21 23:04:08 +00:00
#[rustfmt::skip]
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
static HASH_BYTES: [u8; 20] = [
0x13, 0x20, 0x72, 0xdf,
0x69, 0x09, 0x33, 0x83,
0x5e, 0xb8, 0xb6, 0xad,
0x0b, 0x77, 0xe7, 0xb6,
0xf1, 0x4a, 0xca, 0xd7,
];
let hash = ripemd160::Hash::from_slice(&HASH_BYTES).expect("right number of bytes");
assert_tokens(&hash.compact(), &[Token::BorrowedBytes(&HASH_BYTES[..])]);
assert_tokens(&hash.readable(), &[Token::Str("132072df690933835eb8b6ad0b77e7b6f14acad7")]);
}
}
#[cfg(bench)]
mod benches {
use test::Bencher;
hashes: Run the formatter Run `cargo +nightly fmt`, no other manual changes.
2023-02-21 23:25:12 +00:00
use crate::{ripemd160, Hash, HashEngine};
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
#[bench]
pub fn ripemd160_10(bh: &mut Bencher) {
let mut engine = ripemd160::Hash::engine();
let bytes = [1u8; 10];
hashes: Run the formatter Run `cargo +nightly fmt`, no other manual changes.
2023-02-21 23:25:12 +00:00
bh.iter(|| {
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
engine.input(&bytes);
});
bh.bytes = bytes.len() as u64;
}
#[bench]
pub fn ripemd160_1k(bh: &mut Bencher) {
let mut engine = ripemd160::Hash::engine();
let bytes = [1u8; 1024];
hashes: Run the formatter Run `cargo +nightly fmt`, no other manual changes.
2023-02-21 23:25:12 +00:00
bh.iter(|| {
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
engine.input(&bytes);
});
bh.bytes = bytes.len() as u64;
}
#[bench]
pub fn ripemd160_64k(bh: &mut Bencher) {
let mut engine = ripemd160::Hash::engine();
let bytes = [1u8; 65536];
hashes: Run the formatter Run `cargo +nightly fmt`, no other manual changes.
2023-02-21 23:25:12 +00:00
bh.iter(|| {
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
engine.input(&bytes);
});
bh.bytes = bytes.len() as u64;
}
}