Yes, you could use the HKDF-expand function to expand the bits of the key to a certain size and then use HKDF-extract to derive a key from it again. Note that the resulting key is not identical to the key you've started with. You can use the HKDF-expand again to derive one or more multiple keys with any size from the extracted key material.
HKDF internally ...
From Ptaeck's site (here) (You linked this)
It’s complicated. It’s a wide-block tweakable mode built out of a narrow-block tweakable mode, it uses two keys unnecessarily, and it uses ciphertext stealing to handle variable-length inputs. Another way to say “complicated” is “hard to prove correct”.
This essentially means that it's easy to implement ...
In what's described, nothing makes B sure that A sent the message. And that can't be obtained without some secret on A's side.
A common solution is to have A sign the (e.g. encrypted) message, and B check the signature.
A PKI (perhaps, implemented using digital certificates) can help ensure B uses A's genuine public key, which is required for this proof or ...
There are 2 major types of mode of operation:
The mode requires an initialization vector, which is subdivided into
1.1. a random IV. AES-CBC falls under this category, and
1.2. a unique nonce. AES-GCM and AES-CCM falls under this category.
For either of these subcategory, you should use a mode that provides authenticity guarantee (ideally choose an ...
Here is how these things are done in practice:
Feed entropy to a CSPRNG
Use CSPRNG to generate master secret (in your case a very large one)
Use master secret to encrypt messages
Use CSPRNG to generate "salt"
Use HKDF with master secret and salt to generate ephemeral pseudo-random numbers (encryption keys, IVs, MAC keys...)
Encrypt and protect ...