# AES-CTR security if S-boxes substituion is omitted?

I understand why s-boxes are needed in general especially when ECB mode is used(because of using the same key for encryption of other blocks)but I wonder if it's still relatively secure if we omit S-boxes substitution step in these circumstances

• using AES-CTR mode to make sure the same key with the same blocks will encrypt to different ciphertexts
• if we select a total random key

I'm asking since this way it seems that it's like we encrypting in a similar manner(not exactly) to one-time pad encryption since the result of encryption(that will get x-ored with plaintext) will be random. I know that using S-boxes will increase the security but is this way fine for non-top-secret documents, so we can get some extra performance for like embedded devices, without sacrificing too much in terms of security, also what kind of attacks can be used.

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.

1. You use a new key for each block. This is useless.

1. one uses so many keys to encrypt messages
2. Instead of this use OTP with the key that has other problems.
3. one needs to run the key schedule again and again
2. Use one key

1. 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.

• so it would be only vulnerable to KPA or CPA attacks which makes sense because it's trivial to recover key knowing plaintext (simple x-or)in this case but it's secure against ciphertext-only attacks right ? – Khaled Oct 3 '20 at 9:30
• That is can only be answered what else the attacker knows. The can guess and play as it was done OTP. The linear connection is strongly weak!. – kelalaka Oct 3 '20 at 9:32
• @KhaledGaber: no, it would not be secure against ciphertext-only attacks. For example, it would be straight-forward to recover unknown English text encrypted with it, if the text was at least 32 characters long... – poncho Oct 3 '20 at 14:27
• @KhaledGaber: uneven distribution, and the relationship between relations ("tion" is probable, "toie" is less so, even though the individual characters are more probable). 32 characters because you need two related blocks; a single block gives an effectively random value, the second block has a known relationship with the first (and hence the attacker can leverage that relationship) – poncho Oct 3 '20 at 16:20
• The AES key schedule is also using the S-box. Not sure whether this makes a difference here, – Paŭlo Ebermann Oct 3 '20 at 23:41