1

Pretty much every cipher or hash I've seen has multiple rounds the are designed to be run serially one after the other. Has anyone ever designed a fully parallel cipher or hash? This would be one where all rounds are executed in parallel and then the results are combined in some way such as addition or XOR.

It's mostly a theoretical question. It just occurred to me that I've never seen nor heard of such a thing.

It would be interesting from a performance perspective since you could use wide SIMD instructions to compute many rounds at once. It would also be easier to implement in hardware to run in one clock cycle.

Adam Ierymenko
  • 916
  • 6
  • 20

1 Answers1

2

Rounds in block ciphers, and in the inner compression or sponge function of a hash, are run sequentially for a security reason: it increases diffusion, which is necessary for security. Examples include the 10, 12 or 14 rounds of AES-128, -192 or -256; and the 64 or 80 rounds of SHA-2. We just do not know how to make a secure cryptographic primitive operating on a moderate-sized block that's secure, deeply parallel, and not very much more costly than what we use today.

Parallelism can and is used at a higher level. One of the virtues of CTR is that parallel implementations compatible with sequential implementations is easy. That applies to AES (in multi threaded implementations or parallel hardware), ChaCha, Gimli (which are amenable to SIMD implementation). Modern hashes often have a provision for parallel implementation using Merkle hash trees (often, just two-levels; e.g. ParallelHash of NIST SP 800-185), but that's at the cost of increasing complexity of non-parallel implementations, which I think is part of why it so far did not catch up in daily practice.

fgrieu
  • 149,326
  • 13
  • 324
  • 622