An Sbox is a necessary condition for the security of the AES or a similar block cipher but may not be sufficient. We can list all AES operations on a high level as
- SubBytes – a non-linear substitution step where each byte is replaced with another according to a lookup table.
- ShiftRows – a transposition step where the last three rows of the state are shifted cyclically a certain number of steps.
- MixColumns – a linear mixing operation that operates on the columns of the state, combining the four bytes in each column.
wonder if it's still relatively secure if we omit S-boxes substitution step in these circumstances
If you omit the SubBytes then the new AES cipher will be a completely linear cipher. That is a complete failure for a block cipher. When the attacker, in the simple attack, gets a known-plaintext then they will set up linear equations in total 128 for any AES. If there is no linear dependency on the equation, then they can solve AES-128 with a single-known plaintext pair.
Your design has no KPA security and in modern cryptography, we at least require CPA security.
using AES-CTR mode to make sure the same key with the same blocks will encrypt to different ciphertexts
I've got two understandings.
You use a new key for each block. This is useless.
- one uses so many keys to encrypt messages
- Instead of this use OTP with the key that has other problems.
- one needs to run the key schedule again and again
Use one key
- KPA attack can break this.
this way it seems that it's like we encrypting in a similar manner(not exactly) like one-time pad encryption since the result of encryption(that will get x-ored with plaintext) will be random.
Not really random, linearly depend on the key.
Instead in modern Cryptography what we do, we turn a PRF or PRP into a stream cipher like CTR mode. PFR can work since CTR mode doesn't require the reverse of the PRF. So that we can use one key with one key schedule for a long time. AES-CTR or ChaCha are examples of among the many. AES is believed but not proven to be a PRP. And. remember that for CTR mode one should not use a key-IV pair again.
For file encryption, it is better to use AES-GCM or ChaCha20-Poly1305 which also provides integrity and authentication. AES-GCM is faster since the hardware support like the Intel's AES-NI. The blow in my machine for AES-128 NI
openssl speed -elapsed -evp aes-128-ctr
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-ctr 556160.77k 1822893.03k 3765397.08k 5115820.71k 5694253.74k 5739358.89k
If there is hardware support for ChaCha and Poly1305 it can beat AES.