# Is there a symmetric cipher that is explicitly designed to be slow?

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?

• Huh? What's wrong with using a password hash / PBKDF and using the result for the encryption? And upping the rounds seems a lot like the iteration count in a PBKDF - there is not much more you can do to make something provable slow. – Maarten Bodewes Oct 13 '18 at 16:26
• @MaartenBodewes I probably shouldn't have said "provably slow", I should have said "slow". Mainly, it's because I'm looking for a key schedule and data that are linked. I'm looking for something based on structure that I need for a test. The semiconductors move the power from the faster unit to the slower unit so that the completion times match for the units. A cipher just has the ideal architecture for a test that I need, even if it's a terrible cipher, it's good for this specific test. – b degnan Oct 13 '18 at 16:46
• Could you explain in more detail what is wrong with upping the number of rounds? – Maarten Bodewes Oct 13 '18 at 16:48
• @MaartenBodewes Nothing if the structure was correct. Argon2 is the only PBKDF that I am familiar, and it has the wrong structure for what I'm trying to do in the framework that I have. I'm looking at this from hardware out perspective. I'm probably going to just use SIMON but give it a million rounds. – b degnan Oct 13 '18 at 17:07
• security.stackexchange.com/questions/52379/… – kelalaka Oct 13 '18 at 19:13

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.

• Why not multiple encryptions ( for example with key++?) – kelalaka Oct 13 '18 at 17:53
• That would be "the encryption step of a block cipher". Rewrote. – Maarten Bodewes Oct 13 '18 at 17:56
• Another one; use FHE AES, better FHE Speck – kelalaka Oct 13 '18 at 18:32
• That's very specific. It may require an answer instead of a comment to show how the requirements can be fulfilled with FHE Speck. I'm very much in favor of competing answers and proud of my sportsmanship badge. Too few recent additions for that badge! – Maarten Bodewes Oct 13 '18 at 18:42

Normally, due to $$Time=Money$$ principle ciphers are not designed to be slow. And, even there is always a race for 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 in the Maarten's answer. This will remove the complications of the key schedule.

Update

RSA key-gen the time; as Maarten's comment

time openssl genrsa 1000
real    0m0,016s

time openssl genrsa 10000
real    0m15,157s

time openssl genrsa 100000
real    5631m12,258s that is 3.91 days


Finally finished and 1000000 is far from my laptop.

• It's "Maarten", sorry, Dutch name. 10000000 digit (what's a digit? don't you mean bit?) RSA is not practical because the key generation would take waaaaaaaaaaay more time than the actual encryption. – Maarten Bodewes Oct 13 '18 at 19:44
• @MaartenBodewes sorry, Corrected the name. The question is not about security, use well-known Mersenne primes – kelalaka Oct 13 '18 at 19:52