I would first draw comparisons between an existing PRP like AES, that is known to be secure, and Keccak. The structure of Keccak and AES is very similar with the exception of some design choices as they fundamentally have different use cases, but regardless of their functional differences both are resistant against known cryptographic attacks. At their core they are both PRP’s, and support forward/inverse operations. Symmetric encryption is accomplished with AES by XORing an equal length KEY and MESSAGE. Keccak leverages state truncation to ensure that input recovery is impossible, and thus satisfies the standard hash function requirement of being non-invertible. To further demonstrate interoperability I would ask if AES could function as a hash digest, by leveraging state truncation, but the answer to that question is almost certainly no, without extensive algorithm modifications.
Now it’s necessary to demonstrate the similarities between the sub-functions that comprise both Keccak and AES. Below are the approximate complimentary functions between the two permutations.
$$AES \approx KECCAK$$
SubBytes() $\approx$ Chi():
This is where you correctly identified the 2^5 bit S-box in Keccak(), and with regard to your question about whether or not this is a good S-Box…I don’t know. If you were inclined to run this function with a look up table there would be design considerations that should be considered to ensure it runs in constant time, in my case I tried using Grey Code to mitigate these timing issues. Although if you’re going to live and die by Kerckhoff's Principle all cipher components must not only be public, but the most insecure cipher implementation must be used! Then consider banking systems, and understand that Kerckhoff's Principle is pure garbage.
ShiftRows() $\approx$ Rho()/Pi():
The two functions aren’t exactly the same since AES() is rotating bytes while Keccak() is rotating bits. Furthermore Keccak() acts on both columns and rows, while AES acts only on rows. But I think it's still an appropriate comparison.
MixColumns() $\approx$ Theta():
This comparison is a stretch, and is responsible for the performance difference that you referred to in your question. This also has the potential for adding security as it's the only function where tweaking Keccak() parameters might be safe. If I were to build a cipher out of Keccak() I would include a secret number of iterations of Theta() in the design. The NIST did this when they torpedoed the FIPS-202 specification by omitting the left circular rotation. Technically their test vectors don't match their algorithm specification, which is exactly what I would have done to protect myself in the event of a catastrophic break of SHA-3. But I can only speculate.
N/A $=$ Iota():
Now you mentioned in your question you would use Iota() to insert a key schedule into Keccak(). I would probably do something similar, but depends on if you're trying to build a symmetric or asymmetric encryption scheme. If I was building a symmetric encryption scheme with Keccak() I would generate one 1600 bit key and one 1536 bit key. Use the first for the initialization vector for Theta(), and the second to be inserted into Iota().
AddRoundKey() $=$ N/A:
Keccak() was not developed for symmetric encryption so it stands to reason there was no step for key insertion. Although the bird's method would probably work. See above or below:
$$E_k(m) = F(m \oplus k) \oplus k$$
Is there any cryptanalysis of block ciphers that are unbalanced in such a fashion?
Yes, any research completed on Theta() would meet this particular criteria. Although you may already have that link.
And my own testing:
for i in range(len(set_0)):
for x in range(len(set_1)):
#A filter to be used in CRYPTO_REDUCTION() to structure the data for conclusion
for i in range(len(nested_lists)):
for x in range(len(nested_lists[i])):
for i in range(len(var_sets)):
for i in range(1,len(var_sets)):
if len(to_check) > len(var_sets[i]):
if len(to_check) < len(var_sets[i]):
for i in range(len(var_sets)):
YES, because any other argument would require proving both AES and Keccak insecure. Don't use any of this for production code. If any of this answer is incorrect please make corrections.