-
Notifications
You must be signed in to change notification settings - Fork 101
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
Comments
This was referenced Oct 17, 2023
2 tasks
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
The AES intrinsics are not correctly implemented on ARM. These are the implementations (stripped of compiler directives for posterity):
In detail, we see the following intrinsic for x86:
This is
xor ^ MixColumns(SubBytes(ShiftRows(value)))
. For ARM on the other hand we have:This is
MixColumns(SubBytes(ShiftRows(xor ^ value)))
.This difference goes wrong in a nuclear fashion in the final step of the specialized hash:
The first step of
aesenc(combined, combined)
on ARM iscombined ^ combined
, which simplifies to... the constant 0. That is, aHash's specialized hash implementation used byhash_one
on ARM is always a constant value.The text was updated successfully, but these errors were encountered: