# Is it possible to utilize an AES-128 encryption hardware unit for AES-256?

There exist processors (for example ARM v8/v9 archicteture based), which cannot do AES-256 hardware based, but are equipped with AES-128 encryption hardware units.

Is it possible to utilize an AES-128 encryption hardware unit in some way to speed up the calculation of AES-256?

• If you have AES-NI (access to the hw implementation of the round functions and the key schedule) style access, yes, if not, no. – SEJPM Apr 8 '16 at 19:07
• @SEJPM: I've seen other AES hardware implementations that use a pre-expanded key schedule, so the answer is "maybe" – poncho Apr 8 '16 at 19:21
• it depends. Which processor? How does the AES-128 encryption hardware unit work on that processor? – D.W. Apr 9 '16 at 0:18
• @D.W. Thank you for asking, in my case it is a NXP i.MX ARM9 processor. However, I was more curious, if this is possible in general and maybe even already being done. – 0laf Apr 9 '16 at 11:19
• Please note that AES-128 is not that much less secure than AES-256. – Sebb Apr 10 '16 at 10:29

There are two important differences between AES-128 and AES-256:

• AES-128 has 10 rounds, AES-256 has 14

• The key expansion process (that is, how they generate subkeys) is different

If your AES-128 encryption hardware just takes a plaintext block and a 128 bit key, and produces a ciphertext block, well, no, there's not much you can do. In this case, the hardware knows the AES-128 subkey expansion process, and there's nothing you can do to ask it to do the AES-256 expansion process instead.

However, if the hardware takes the plaintext block and the $11 \times 128$ bit expanded key, yes, there are things you can do.

The obvious approach would be (in the encrypt direction) to perform the first four rounds in software (stopping just before the addround transform at the end of the fourth round); then hand the intermediate block to hardware to compute the last 10 rounds.

In your key expansion process, you'd run the AES-256 key expansion process in software; you'd keep the first 4 generated subkeys for your software routine; you'd hand the last 11 subkeys to hardware as your expanded "AES-128" key.

This idea won't be as fast as doing AES-256 in hardware; however it should be faster then performing everything in software.

Also, you want hardware to handle the last round (in the encrypt direction); that last round is handled slightly differently - while you can adjust for it, there's no reason to.

It depends how the “AES-128 encryption hardware units” you mention are actually defined.

I've already encountered processors that allow to independently compute AES operations such as $\texttt{SubBytes}$ and $\texttt{MixColumns}$ – which are the same regardless the key size involved (128 or 256 bits). In that case: yes, it can speed up the calculation for both AES-128 and AES-256.

But if the hardware unit computes a whole AES-128 from beginning to end, I don't see how to use it for a 256-bit key version.