Before, when the actually passed key was too long, the extra bytes were silently
ignored. This can lead to all sorts of trouble, so ... don't do that.
The original intention was maybe to support non-integer amounts of key bytes.
But that doesn't happen anyway with AES.
ByteBuffer::slice_view() allocates a new ByteBuffer object,
which as a RefPtr and everything.
Nowadays it should probably return a Bytes / Span<u8>, but AES was only
using slice_view() to extract the pointer again. So just add ady a
range check at the top, and do pointer arithmetic to do the same thing
faster.
Reduces time to run `disasm /bin/id` by a bit under 40%,
from ~8.3s to ~5s (min-of-3 runs).
This is in preparation for the upcoming Galois/Counter mode, which
conventionally has 12 bytes of IV as opposed to CBC's 16 bytes.
...Also fixes a lot of style issues, since the author finally found the
project's clang config file in the repository root :^)
This commit fixes up the following:
- HMAC should not reuse a single hasher when successively updating
- AES Key should not assume its user key is valid signed char*
- Mode should have a virtual destructor
And adds a RFC5246 padding mode, which is required for TLS