Score:-1

How expensive is it to migrate from AES-128 to AES-256

nl flag

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

kelalaka avatar
in flag
[40% overhead of AES-256 over AES-128 with AES-NI](https://crypto.stackexchange.com/a/76746/18298), 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.
fgrieu avatar
ng flag
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.
gnasher729 avatar
kz flag
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
Score:3
in flag

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...

Richie Frame avatar
cn flag
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
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.