[Libre-soc-dev] AES and block modes

[Jacob Lifshay]

On Thu, Dec 10, 2020, 16:37 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On 12/11/20, Jacob Lifshay <programmerjake at gmail.com> wrote:
> > On Thu, Dec 10, 2020, 16:14 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > wrote:
> >
> >> you make a hardware triangle fill unit like Jeff did, it's not going
> >> to do multiplication, is it?
> >>
> >
> > it might, since the per-pixel function is just a vec4 dot product
> followed
> > by a reciprocal and a pile of mul-adds.
>
> aw gad, that's funny. i was wondering if i should pick a completely
> obscure example.
>
>
> > actually, I'm pretty sure your wrong here. for 256-bit AES, the key
> > schedule changes but each of the actual encryption steps still do the
> exact
> > same 128-bit block operation.
>
> mmm... the S-box yes, that is just a bunch of byte level independent
> operations.  likewise XOR is bitlevel independent, no intermixing
> between bytes.
>
> if 256 bit Rijndael *genuinely* does no mixing between bytes across 2
> sets of 128 bit blocks that is extremely poor design.


Quoting Wikipedia's AES article:
> For AES, NIST selected three members of the Rijndael family, each with a
> block size of 128 bits, but three different key lengths: 128, 192 and 256
bits.

mixing at larger than 128-bit blocks is entirely handled by block modes on
top of AES or any other block cipher -- see:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

my personal favorite mode is either CTR or one of the AEAD modes.

consequently i
> have difficulty believing it, although most of my work back in 2002-4
> focussed on Rijndael 128, so it's been a while.
>

I think you might be mistakenly thinking that encryption algorithms must
use just the block cipher with no other operations to convert the input to
the output (aka. the ECB block cipher mode which is known to be
broken/weak), which is totally wrong. I fell into that trap myself when I
was younger.

>
> my point was to try to pick another example instruction (any
> instruction) that had specialist targetted uses but was a not
> insignificant block of silicon.
>

yup, I completely get that.

Jacob