[Cryptography] Stupid question on S-boxes

[Henry Baker]

At 05:40 PM 1/24/2019, Bill Cox wrote:
>S-boxes leak secret key info through cache timing attacks.  IMO, they should be avoided.

I'm not sure what you're saying here.

Are you saying that you shouldn't implement S-boxes in software?  Clearly
S-boxes are *already* being implemented in software, although they tend to
be *small* and *a priori fixed* S-boxes -- e.g., DES, AES.  So yes, the
same sorts of masking and other side-channel defenses continue to be
required.  So "cache timing attacks" can't be a legitimate argument
against the use of "large" -- e.g., 128-bit -- S-boxes, per se.

You might argue that a 128-bit S-box is *too* large to implement in
proper hardware, and that may be a (current) legitimate concern.  But
in a 7nm world, there's less and less that's "too large".

You might be suggesting that the current "large" S-boxes can't
be implemented sufficiently efficiently to be useful in practise,
and you might be (currently) correct about that.  However, as
the history of hardware has shown, critical tasks tend to get
optimized quite quickly, so I'm currently asking a theoretical
question that might eventually become non-theoretical.

You might also worry that I'm suggesting a large *dynamic* S-box,
whose construction might somehow be encoded into a private key.
I'm not (currently) suggesting this, as AES has done just fine
with a priori fixed S-boxes, so I suspect that dynamic S-boxes
won't be necessary, although some have argued that dynamic
S-boxes avoid rainbow table-type attacks.

Once again, I'm suggesting that the Feistel structure and
multiple rounds is an attempt to build larger S-boxes from
smaller ones, and we're getting to the point where these
newer constructions may be better than the Feistel/round
mechanisms for performing this recursive construction. 
That's my basic question.