Mixing
Is there a symmetric cipher that is explicitly designed to be slow?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
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?
symmetric reference-request
asked 4 hours ago
b degnan
1,2751521
add a comment |Â
up vote
1
down vote
favorite
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?
symmetric reference-request
asked 4 hours ago
b degnan
1,2751521
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
3 hours ago
@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
3 hours ago
Could you explain in more detail what is wrong with upping the number of rounds?
– Maarten Bodewes
3 hours ago
@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
3 hours ago
security.stackexchange.com/questions/52379/…
– kelalaka
58 mins ago
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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?
symmetric reference-request
asked 4 hours ago
b degnan
1,2751521
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?
symmetric reference-request
symmetric reference-request
asked 4 hours ago
b degnan
1,2751521
asked 4 hours ago
b degnan
1,2751521
asked 4 hours ago
b degnan
1,2751521
asked 4 hours ago
b degnan
1,2751521
asked 4 hours ago
b degnan
1,2751521
1,2751521
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
3 hours ago
@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
3 hours ago
Could you explain in more detail what is wrong with upping the number of rounds?
– Maarten Bodewes
3 hours ago
@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
3 hours ago
security.stackexchange.com/questions/52379/…
– kelalaka
58 mins ago
add a comment |Â
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
3 hours ago
@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
3 hours ago
Could you explain in more detail what is wrong with upping the number of rounds?
– Maarten Bodewes
3 hours ago
@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
3 hours ago
security.stackexchange.com/questions/52379/…
– kelalaka
58 mins ago
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
3 hours ago
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
3 hours ago
@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
3 hours ago
@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
3 hours ago
Could you explain in more detail what is wrong with upping the number of rounds?
– Maarten Bodewes
3 hours ago
Could you explain in more detail what is wrong with upping the number of rounds?
– Maarten Bodewes
3 hours ago
@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
3 hours ago
@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
3 hours ago
security.stackexchange.com/questions/52379/…
– kelalaka
58 mins ago
security.stackexchange.com/questions/52379/…
– kelalaka
58 mins ago
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
1
down vote
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.
answered 44 mins ago
kelalaka
1,018217
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
27 mins ago
2
@MaartenBodewes sorry, Corrected the name. The question is not about security, use well-known Mersenne primes
– kelalaka
20 mins ago
add a comment |Â
up vote
1
down vote
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.
answered 2 hours ago
Maarten Bodewes
49.1k569182
1
Why not multiple encryptions ( for example with key++?)
– kelalaka
2 hours ago
That would be "the encryption step of a block cipher". Rewrote.
– Maarten Bodewes
2 hours ago
Another one; use FHE AES, better FHE Speck
– kelalaka
1 hour ago
1
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
1 hour ago
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
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.
answered 44 mins ago
kelalaka
1,018217
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
27 mins ago
2
@MaartenBodewes sorry, Corrected the name. The question is not about security, use well-known Mersenne primes
– kelalaka
20 mins ago
add a comment |Â
up vote
1
down vote
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.
answered 44 mins ago
kelalaka
1,018217
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
27 mins ago
2
@MaartenBodewes sorry, Corrected the name. The question is not about security, use well-known Mersenne primes
– kelalaka
20 mins ago
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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.
answered 44 mins ago
kelalaka
1,018217
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.
answered 44 mins ago
kelalaka
1,018217
edited 25 mins ago
answered 44 mins ago
kelalaka
1,018217
answered 44 mins ago
kelalaka
1,018217
answered 44 mins ago
kelalaka
1,018217
1,018217
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
27 mins ago
2
@MaartenBodewes sorry, Corrected the name. The question is not about security, use well-known Mersenne primes
– kelalaka
20 mins ago
add a comment |Â
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
27 mins ago
2
@MaartenBodewes sorry, Corrected the name. The question is not about security, use well-known Mersenne primes
– kelalaka
20 mins ago
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
27 mins ago
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
27 mins ago
2
2
@MaartenBodewes sorry, Corrected the name. The question is not about security, use well-known Mersenne primes
– kelalaka
20 mins ago
@MaartenBodewes sorry, Corrected the name. The question is not about security, use well-known Mersenne primes
– kelalaka
20 mins ago
add a comment |Â
up vote
1
down vote
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.
answered 2 hours ago
Maarten Bodewes
49.1k569182
1
Why not multiple encryptions ( for example with key++?)
– kelalaka
2 hours ago
That would be "the encryption step of a block cipher". Rewrote.
– Maarten Bodewes
2 hours ago
Another one; use FHE AES, better FHE Speck
– kelalaka
1 hour ago
1
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
1 hour ago
add a comment |Â
up vote
1
down vote
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.
answered 2 hours ago
Maarten Bodewes
49.1k569182
1
Why not multiple encryptions ( for example with key++?)
– kelalaka
2 hours ago
That would be "the encryption step of a block cipher". Rewrote.
– Maarten Bodewes
2 hours ago
Another one; use FHE AES, better FHE Speck
– kelalaka
1 hour ago
1
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
1 hour ago
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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.
answered 2 hours ago
Maarten Bodewes
49.1k569182
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.
answered 2 hours ago
Maarten Bodewes
49.1k569182
edited 14 mins ago
answered 2 hours ago
Maarten Bodewes
49.1k569182
answered 2 hours ago
Maarten Bodewes
49.1k569182
answered 2 hours ago
Maarten Bodewes
49.1k569182
49.1k569182
1
Why not multiple encryptions ( for example with key++?)
– kelalaka
2 hours ago
That would be "the encryption step of a block cipher". Rewrote.
– Maarten Bodewes
2 hours ago
Another one; use FHE AES, better FHE Speck
– kelalaka
1 hour ago
1
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
1 hour ago
add a comment |Â
1
Why not multiple encryptions ( for example with key++?)
– kelalaka
2 hours ago
That would be "the encryption step of a block cipher". Rewrote.
– Maarten Bodewes
2 hours ago
Another one; use FHE AES, better FHE Speck
– kelalaka
1 hour ago
1
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
1 hour ago
1
1
Why not multiple encryptions ( for example with key++?)
– kelalaka
2 hours ago
Why not multiple encryptions ( for example with key++?)
– kelalaka
2 hours ago
That would be "the encryption step of a block cipher". Rewrote.
– Maarten Bodewes
2 hours ago
That would be "the encryption step of a block cipher". Rewrote.
– Maarten Bodewes
2 hours ago
Another one; use FHE AES, better FHE Speck
– kelalaka
1 hour ago
Another one; use FHE AES, better FHE Speck
– kelalaka
1 hour ago
1
1
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
1 hour ago
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
1 hour ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f63083%2fis-there-a-symmetric-cipher-that-is-explicitly-designed-to-be-slow%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
3 hours ago
@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
3 hours ago
Could you explain in more detail what is wrong with upping the number of rounds?
– Maarten Bodewes
3 hours ago
@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
3 hours ago
security.stackexchange.com/questions/52379/…
– kelalaka
58 mins ago