Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Critical issue: aHash's specialized hash is constant value 7161677110969590627 on ARM #166

Closed
orlp opened this issue Oct 17, 2023 · 0 comments

Comments

@orlp
Copy link
Contributor

orlp commented Oct 17, 2023

The AES intrinsics are not correctly implemented on ARM. These are the implementations (stripped of compiler directives for posterity):

pub(crate) fn aesenc_x86(value: u128, xor: u128) -> u128 {
    use core::arch::x86_64::*;
    unsafe {
        let value = transmute(value);
        transmute(_mm_aesenc_si128(value, transmute(xor)))
    }
}

pub(crate) fn aesenc_arm(value: u128, xor: u128) -> u128 {
    use core::arch::aarch64::*;
    unsafe {
        let value = transmute(value);
        transmute(vaesmcq_u8(vaeseq_u8(value, transmute(xor))))
    }
}

In detail, we see the following intrinsic for x86:

_mm_aesenc_si128(value, transmute(xor))

This is xor ^ MixColumns(SubBytes(ShiftRows(value))). For ARM on the other hand we have:

vaesmcq_u8(vaeseq_u8(value, transmute(xor)))

This is MixColumns(SubBytes(ShiftRows(xor ^ value))).

This difference goes wrong in a nuclear fashion in the final step of the specialized hash:

#[cfg(feature = "specialize")]
fn short_finish(&self) -> u64 {
    let combined = aesdec(self.sum, self.enc);
    let result: [u64; 2] = aesenc(combined, combined).convert();
    result[0]
}

The first step of aesenc(combined, combined) on ARM is combined ^ combined, which simplifies to... the constant 0. That is, aHash's specialized hash implementation used by hash_one on ARM is always a constant value.

TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 12, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 12, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 12, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 12, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 13, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 13, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 13, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 13, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 13, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 13, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 13, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 16, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 16, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
akitamiabtc pushed a commit to akitamiabtc/yuv-lightning that referenced this issue Jun 17, 2024
tkaitchuck/aHash#196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.

Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
tkaitchuck/aHash#163 and
tkaitchuck/aHash#166.

Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants