keccak: add ParKeccakP1600 struct

[tarcieri]

Adds a struct which holds multiple parallel Keccak states, which can be used to take advantage of various parallel SIMD implementations of Keccak.

The struct is const generic around the number of parallel states P.

Also adds a KeccakP1600Permute trait and impls it for ParKeccakP1600 where P is one of 1, 2, 4, or 8. These match the sizes supported by the SIMD backends presently available in XKCP, where 8-way parallelism is supported for AVX-512.

The "parallel" implementation currently uses a simple loop combined with our existing single-state Keccak impls, but the idea is we can plug in various target-specific SIMD implementations in the future.

Additionally, changes the single-state KeccakP1600 to be a newtype for ParKeccakP1600<1>. The advantage of a newtype over a type alias is the AsRef and From impls don't need to deal with arrays.

[newpavlov]

I don't think it's a good way to expose support for parallel processing. How do you intent for this API to be used in practice?

I think we need something similar to the cipher backend traits here. In other words, downstream users are either able to use this capability and then they should use optimal parallelism for the selected (potentially at runtime) backend, or they work in sequential fashion.

[tarcieri]

Several Keccak-based constructions are designed to leverage this sort of parallel computation. The main one we implement that could benefit is k12 / KangarooTwelve, which has a built-in parallel mode designed to leverage exactly this sort of n-way parallelism for long messages, namely it's a tree hashing algorithm based on Sakura encoding.

There are other Keccak-based constructions I'm not terribly familiar with and we don't currently implement which can also benefit and may be of interest to others, like Kravatte and Xoofff.

You can look in XKCP for how the parallel implementations are structured:

• https://github.com/XKCP/XKCP/blob/master/lib/high/KangarooTwelve/KangarooTwelve.c
• https://github.com/XKCP/XKCP/blob/master/lib/high/Kravatte/Kravatte.c
• https://github.com/XKCP/XKCP/blob/master/lib/high/Xoofff/Xoofff.c

They're all designed to support up to at least 8-way parallelism.

This kind of parallelism seems to naturally fall out of the SIMD implementations too, e.g. the existing ARMv8 ASM we already have has always been capable of 2-way parallelism, it just wasn't exposed (and should be by #112) simply by filling the full vector register width, and if I were to port the SSSE3/AVX2 backends, they're capable of it as well. So I think we should at least expose it, because it's generally useful for many Keccak-based constructions.

[newpavlov]

Yes, I know about k12. My point was that we should use the parallelism number which is optimal for selected backend (e.g. 2 in the case of the ARM backend) instead of the maximum number supported by the implemented algorithm (e.g. 8).

So I think we should at least expose it, because it's generally useful for many Keccak-based constructions.

I agree that we should expose it. My objection was towards the currently implemented API.

[tarcieri]

If you'd be fine with adding 2-way parallelism today, we can start there, as that is easily exposed by our existing ARMv8 implementation and an SSSE3 implementation on x86(_64).

[newpavlov]

Give me time until the end of the week. I will try to draft an alternative API to better demonstrate my point.

[tarcieri]

Cool. I'm not too hung up on the API, just having some way to expose it.

I'll continue working on the SIMD backends, and hopefully we can support 2-way parallelism on both ARMv8 and x86(_64) using intrinsics-based implementations with CPU feature autodetection that are on-by-default and avoid the need for any cfg, like we have in other crates with intrinsics support

[newpavlov]

See #113.