How feasible would it be to migrate from AES-128 to AES-256?

  • 1
    $\begingroup$ 40% overhead of AES-256 over AES-128 with AES-NI, And the increased rounds 10 of AES-128 to 14 for AES-256 is verified. Is this what you wanted or deeper than this like the cost of generating double-sized keys and storing them, available hardware, password strength to derive keys, etc. $\endgroup$
    – kelalaka
    Nov 23 at 21:01
  • 3
    $\begingroup$ On the other hand, if the users already hold 128-bit keys, the cost of moving to 256-bit keys is at least the cost of distribution of new keys to all users. In a business where millions users hold their keys on Smart Cards, that cost alone would be a show stopper. $\endgroup$
    – fgrieu
    Nov 23 at 21:12
  • $\begingroup$ You may have the cost of updating the software as well. No good using 256 bit keys if your software doesn’t know what to do with it $\endgroup$
    – gnasher729
    Nov 26 at 17:05

As you may have found out it depends on the specific system where this can be applied. If AES-256 is supported then the algorithmic overhead is usually limited; it would possibly only be a problem when it comes to embedded devices.

As also mentioned, key management is probably the biggest hurdle. Re-establishing keys can be really hard. It can also be very simple; e.g. you could simply reconfigure the cipher suites of TLS, and since the (ephemeral) symmetric session keys are established during the handshake, you would probably not even notice the change. However, if the keys have been pre-distributed then replacing the keys from a trusted source maybe costly, possibly prohibitively so.

For hardware: there are certainly embedded CPU's systems that only support AES-128 hardware acceleration. Due to the puny CPU's it may not be feasible to run AES in software. In that case AES-256 is probably a no go. Most modern CPU's in PC's support AES acceleration for both key sizes on the other hand.

For protocols: AES-256 uses 32 byte keys. This can be an issue if a your key derivation mechanism only outputs smaller amounts of bytes (say PBKDF1 with SHA-1), or is inefficient (say PBKDF2 with SHA-1) if you retrieve too many bytes from it. On the other hand, the block size of AES-128 and AES-256 so if the block cipher is seen as a black box, then the input / output (plaintext / ciphertext) requirements won't change.

Similarly, if you have a large disk that is encrypted with AES-128 then re-encrypting it using AES-256 then you may have to wait a long time before the process is finished, not so much because of AES but because of the I/O.

So without further information: it depends, it can be a single configuration string or it may not even be possible and everything in between...

  • $\begingroup$ the main issue for embedded AES128 with limited memory would probably be a rolling key schedule, that does not store any subkeys except for the active one $\endgroup$ Nov 24 at 17:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.