Release keccak v0.2.0

[newpavlov]

Added

• keccak_backend configuration parameter with armv8_asm, simd,
  and soft-compact values (#105, #106)
• KeccakP1600 struct (#107)

Changed

• Edition changed to 2024 and MSRV bumped to 1.85 (#89)
• Bump cpufeatures dependency to v0.3 (#99)

Removed

• asm, simd, and no_unroll crate features in favor of
  the keccak_backend configuration parameter (#105, #106)
• f1600 and p1600 functions in favor of the KeccakP1600 struct (#107)

Fixed

• Use doc_cfg in place of removed doc_auto_cfg feature (#91)

[tarcieri]

I wanted to look at doing an AVX2 backend before this, particularly for how that might interact with cfg(keccak_backend). Give me another day?

Perhaps we could do preleases to fix the broken hash crates in the meantime?

[newpavlov]

I think it can be done in a patch release? I planned to add the proposed callback API in a future patch release as well. We even could cut a new minor version, since keccak is a private dependency of sha3.

So I would prefer to cut proper releases instead of doing yet another cycle of pre-releases. But I can wait a day, since I don't consider the pre-release crate breakage a big issue.

[tarcieri]

I am still also interested in looking at an intrinsics port of the ARMv8 assembly. Enquiring upstream on XKCP, I don't think the potential performance loss of moving away from a hand-tuned register schedule should be too severe.

If we migrated to intrinsics, we could drop the armv8_asm cfg entirely, which would otherwise be a breaking change or a code wart if we shipped now.

If we do stick with ASM, and add ASM for AVX2 (I was in fact in the middle of working on that, but went on vacation for a few days), I think it might be nice to add a unified keccak_backend="asm" which is fast everywhere regardless of target, in addition to possbile e.g. armv8_asm/avx2_asm cfgs.

(I also think we should figure out how to expose the "timesN" parallel implementations, whose API design might be worth considering before a release to see if we want to make any breaking changes first. The ARMv8 ASM is already set up to be a "times2" implementation IIRC)

[newpavlov]

I think it's fine to do the listed changes in a new breaking keccak release, but I am no rush, so I am fine with postponing the release if you want (for more than a day if needed).

[tarcieri]

Or maybe we could just remove the ARMv8 ASM for now, and I can either add an intrinsics implementation, or we can add it back.

The parallel API would impact something like the newly added KeccakP1600 struct which we've never actually shipped in a prerelease AFAIK. I guess the question is looking at XKCP they support 1X, 2X, 4X, and 8X parallelism, so do we have an API that's generic over 1/2/4/8, or do we treat single-state Keccak completely separately with its own types, and have a parallel implementation that's generic over 2/4/8.

[newpavlov]

Or maybe we could just remove the ARMv8 ASM for now

Nah, I don't think we should bother with it. The asm configuration parameter is somewhat experimental, so IMO it's fine to remove it or change its behavior in a next breaking release. In the worst case scenario the crate would just fallback to the soft backend.