Join Log in
Score:1
Tom avatar Crypto

Key stream instead of key schedule

tf flag
Tom

Let's consider a block cipher in CTR mode. And let's consider a keyed PRNG or just a good PRNG with a seed as the key. The PRNG has to be very fast.

Is it a good idea to put away the key schedule and do "infinite" key scheduling by generating a keystream? Then every block in the cipher will be encrypted with a different key.

Of course, even a fast PRNG needs some time to generate a few 128 -bit keys for a cipher. But doesn't this greatly increase the security of such an algorithm? If the algorithm itself is a very fast primitive (say, as fast as Chacha20), it should have excellent security and good speed if associated with a "key schedule stream" like this.

However, I suspect that the speed of such a solution may be a significant obstacle. Okay, so let's make a change each time the algorithm is repeated (single encryption)--flipping only one bit of the key per round. If the algorithm requires one key per round and has ten rounds, we only need ten bits. The PRNG will generate such bits very quickly. Then the keys are changed after each encryption, not much (we change only one bit in every key), but it should be a huge obstacle for the attacker.

Maybe we could use something simple such as two rounds of AES but not add another two rounds to the cipher. So, let's use this to generate a keystream to mix with the keys in a new encryption.

My question is about the disadvantages of such a solution. As far as I know, it is not used - why? In other words, why do we use constants and the same keys in rounds (when encrypting vast numbers of messages ) when keys can be modified at a low cost after each encryption; for example, by adding one bit mod 2 (after another encryption, we add another bit on a higher position and so on, changing all 128-bit keys after 128 encryptions).

70
0 + 6
SAI Peregrinus avatar
si flag
SAI Peregrinus
CTR mode is used to turn a block cipher into a stream cipher. Block ciphers are pretty useless for encryption (since they can encrypt one block per key safely) so we use different modes of operation to actually encrypt things with them. There are also native stream ciphers, effectively keyed PRNGs, that don't have a block cipher internally. You're proposing internally keying a block cipher with a stream cipher, then using it in CTR mode to turn it back into a stream cipher. Why not just use the stream cipher directly? What advantages would your construction have?
0
Reply
Tom avatar
tf flag
Tom
The advantage is a higher level of block cipher security. Moreover, if we could build a block cipher improvement with this technology - which is faster and at the same time more secure than the original algorithm - why not use it? If AES with shortened rounds but keying with a stream cipher would be faster, why not do it? Perhaps there are algorithms that can be improved and accelerated this way. Having underlying key generator, independent of the cipher could be big improvement in terms of security, I think.
0
Reply
SAI Peregrinus avatar
si flag
SAI Peregrinus
Leading questions: Would this improve security over a stream cipher? ChaCha20 is (arguably) more secure than AES-256, for the same key size. Using ChaCha20 in place of AES's key schedule would remove the weakness of the key schedule that makes AES weaker, but would it make the resulting cipher slower or faster, and would it be meaningfully more secure than ChaCha20? Why or why not (try to prove these things to yourself)?
0
Reply
Tom avatar
tf flag
Tom
To decide is it worth we have to cut few rounds of AES and replace them by key streaming. No I can't say will it be worth it. But I suspect we can get faster and more secure cipher this way. I asked a question to find out is it obviously bad idea in some way. Of course now I have no idea is it doable with any cipher. But the fact that we use "permanent" keys in cryptography so commonly seems to me incomprehensible from the point of view I have presented.
0
Reply
SAI Peregrinus avatar
si flag
SAI Peregrinus
AES's key schedule is VERY fast. It's not a bottleneck for AES. Replacing it with ChaCha20 would slow things down, and *add no extra security beyond what you get from the stream cipher alone*. Even if you reduced the round count. Also we rarely (if ever) use permanent keys. Most keys (eg for TLS connections) are ephemeral, they get deleted as soon as the connection is closed. Disk encryption keys last longer, of course, but that's mostly because disks have a lot of data and re-encrypting it would be slow, not because the key scheduling is slow (it's not).
0
Reply
Maarten Bodewes avatar
in flag
Maarten Bodewes
We've had other questions that were about replacing the key schedule with something else. The current question has the following problem in my opinion: 1. you somehow use another fast key schedule - now **you have to show** that this is secure or 2. you use a known secure key schedule, in which case **you have to show** the security benefits over using the secure key stream directly.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.