Support 192 and 256-bit keys for AES

[playfulFence]

closes #1234

[jessebraham]

Not a huge fan of just panicking on invalid key length, as there's no way for an application to recover from that. I guess without const_generic_exprs there's not much else we can do other than make the method fallible (which might be preferable?).

@bjoernQ what do you think?

[bjoernQ]

Not a huge fan of just panicking on invalid key length, as there's no way for an application to recover from that. I guess without const_generic_exprs there's not much else we can do other than make the method fallible (which might be preferable?).

@bjoernQ what do you think?

Not exactly nice, true. Fallible would be better or maybe we define an Enum for the keysizes, like

pub enum Key {
  Key16([u8;16),
  #[cfg(any(feature = "esp32", feature = "esp32s2")]
  Key24([u8;24),
  Key32([u8;32),
}

Also don't we define cfg-symbols for the chip? Like #[cfg(any(esp32,esp32s2)]

[jessebraham]

Thanks for the input @bjoernQ. Not quite sure what is best right now, I think making it fallible or the key size enum are both probably fine solutions. So, no strong opinions now, will sleep on it.

[MabezDev]

Can we decide on a path forward here?

[jessebraham]

I've suggested a solution, so has Bjoern. I'm not going to be too picky about what we decide on as long as it doesn't just panic. If nobody else has any input then we should probably just make it fallible and we can revisit it at some other time.

[bjoernQ]

I'm fine with making it fallible for now. I think the Key enum would be a better solution if we don't end up in having a hell lot of key lengths. But for the sake to get this forward - let's make it fallible

[playfulFence]

I think, as Key enum is currently a "nicest" solution, we can proceed with it 🤔

[jessebraham]

I think, as Key enum is currently a "nicest" solution, we can proceed with it 🤔

Sure, that's fine too. A fallible API is probably simpler, though.

[MabezDev]

Let's go with the Key enum, I think we can make the API simpler like @jessebraham was suggesting by adding From<[u8; 16]> impls for Key, meaning the API doesn't get much harder to use, users only need to call into(). We could even add the trait bound for Into<Key> if we wanted to go the extra mile.

[bjoernQ]

LGTM - the key-enum is really the nicer solution

[jessebraham]

LGTM, thanks for making those changes, and thanks for sticking it out through all these review comments!

Review comments have been addressed