Let's say you take a 256 bit key and never use it to encrypt anything. You receive a message with a 16 character unique randomly generated salt pre-pended. You salt your key with the 16 character salt and run it through SHA-256 to create the encryption key used for the first block with AES-256. Afterwards, you take the first hash-resultant key, append the original unused encryption key, hash the result with SHA-256 and create the key used to encrypt the next block. Each block's encryption key is the previous key appended with the never used encryption key hashed with SHA-256. Let's say you used this method in CBC mode. How would it compare to AES-256 used in conventional secret key CBC mode in terms of security and performance?

Also, would this still qualify as block cipher encryption or am I talking about a something that is almost starting to resemble a stream cipher here?

  • What's your motivation for this question? Are you trying to build this? – StackzOfZtuff Oct 3 '15 at 6:13
  • Perhaps this would be better on crypto.SE? – Neil Smithline Oct 4 '15 at 17:04

Performance will be many times slower than AES, any perceived security advantage will be minimal.

The additional key transfer and subkey generation for each block could create a timing attack vector, and you are now loading the primary key into memory for every block, vs AES alone which performs a single key expansion, then saves the subkeys in XMM registers (when using hardware acceleration), where it can then be secured from access by other processes.

The method you are describing turns a hash based stream cipher into a KDF to generate keys for each block. This might be acceptable if you are using CTR mode and are trying to prevent something that is nonce reuse resistant, and you then use the new key for each new message, rather than each block.

From a performance perspective, for each block you perform on average, 2 hash iterations, 1 key expansion, and 14 encryption rounds. SHA-256 takes something like 550 clock cycles (can anyone confirm?) per iteration, 14 rounds of AES with key addition takes something like 101 clock cycles, and the key expansion is up to 136 clock cycles. That gives you 1337 clocks vs 101, a 13.2 times performance disadvantage. Additionally because of the way the keys are generated, you can't really take advantage of multiple cores, another maybe 4X disadvantage, although you can use ECB mode since the key is different for each block.

In all, when compared to ECB and CTR mode on a quad core haswell CPU, you will be around 52 times slower, and 13 times slower than CBC.

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.