I get the same result from your code as from an online JavaScript CRC calculator (0x6F6EE1BF). I would reconsider why you expect the output that you do, it seems unlikely that two unrelated implementations are wrong in the same exact way (though not impossible). I did modify your code a little before running it, because it doesn't compile as is:
error: literal out of range for `u8`
--> src/main.rs:17:21
|
17 | digest.update(&[0xDA1622B4]); //DA 16 22 B4 in bytes
| ^^^^^^^^^^
|
= note: the literal `0xDA1622B4` (decimal `3658883764`) does not fit into the type `u8` and will become `180u8`
= help: consider using the type `u32` instead
= note: `#[deny(overflowing_literals)]` on by default
So I changed the input to &[0xDA, 0x16, 0x22, 0xB4] instead. Though I don't get 96 68 B8 1B either way so this probably isn't the root of the issue.
So it looks like your 0xedb88320 is not a normal polynomial but a reversed polynomial. The corresponding normal polynomial is 0x04c11db7, perhaps the most common CRC-32 polynomial. Therefore, you can use one of the predefined algorithms for this:
use crc::{Crc, CRC_32_ISO_HDLC};
fn main() {
let crc = Crc::<u32>::new(&CRC_32_ISO_HDLC);
let checksum = crc.checksum(&[0xda, 0x16, 0x22, 0xb4]);
println!("{checksum:#x}");
}
This prints 0x1bb86896, which in little-endian order is 96 68 B8 1B, as expected. (To get the checksum in little-endian form, you can call checksum.to_le_bytes().)