mjhjmtu

I am trying to find a symmetric cipher that is explicitly designed to be slow. I realize that this is generally not desirable, but I'd like many cycles and lots of electronic action. I could modify a cipher make a Fiestel network have a million rounds, but I'm trying to find something "provably slow" that is akin to a memory-hard function but without the memory.

The motivation for this is that I want a structured way to create test vectors for an asynchronous IC library that are "random-looking" but repeatable for simulation. It's an easy way for me to keep track and cut up the problem on the cluster. The reason that I don't want to use a hash function is architectural. I want to structure of a key schedule and data schedule with a dependency.

Has anyone ever come across a symmetric cipher design to be slow?

Normally, due to $Time=Money$ principle ciphers are not designed to be slow. And, even there is always a race more secure + faster ciphers. Even, in the beginning, The AES candidate MARS was argued about being slow.

Apart from Maarten answers, I can give some unorthodox examples;

• Use the FHE version of AES, or better


• NSA's Specks' FHE version that is 3624 sec to execute only 11 rounds.


• Use 1000000-bit RSA, the bigger modules the slower.

Of course, there can be a problem with the FHE's, that is the memory requirements of this implementations.

If I were you, I'll go to one cipher with multiple encryptions as Maarten's answer. This will remove the complications of the key schedule.

A memory hard PBKDF (or password hash, same thing, different name) without memory hardness is basically just a repetition of a hash or cipher. In that case you might was well be the repeated application of a block cipher (with an alterated key if needed) or - indeed - increase the number of rounds.

The issue with increasing the number of rounds is that you also need to extend the key schedule. But since you're not trying to achieve more security, you could simply repeat previously calculated keys (if the key schedule itself cannot be easily extended).

Note that bcrypt is a password hash that uses a block cipher rather than a hash function. You could check if that suits your needs.