1
$\begingroup$

Say I have 20 distinct encrypted messages.

Using AES, I am only getting the correct output if I decrypt each of the 20 messages individually.

Is it possible using AES or another method to call my decrypt function on the concatenated 20 messages as one message and get the concatenated decrypted results?

It seems inefficient processing time to call decrypt 20 times.

(Note: I am doing this with raw audio, and interestingly when I decrypt 20 together it sounds like the original but with some clinky noise)-- I want without the clinky noise.

$\endgroup$
3
  • 3
    $\begingroup$ Welcome to Cryptography.SE. The obvious question; which mode of operation are you using? Obviously, you can write such a function with a special format that provides the size of the next chunk, the start to decrypt, and append the chunks. $\endgroup$ – kelalaka May 4 at 10:15
  • 3
    $\begingroup$ “It seems inefficient processing time to call decrypt 20 times.” Did you benchmark it? For messages that are long enough to be useful audio data payloads, the setup time is small compared to the linear data processing time. If your library lets you reuse an operation object with the same key so that it doesn't do the key schedule each time, it's utterly negligible. It's very likely that you're trying to solve a problem that doesn't exist. $\endgroup$ – Gilles 'SO- stop being evil' May 4 at 10:42
  • 1
    $\begingroup$ My mistake was I was doing the key scheduling for each chunk. Now that I am reusing- you are correct it is negligible. Thank you. $\endgroup$ – A S May 4 at 11:05
2
$\begingroup$

Stating "AES" is not enough to specify some encryption. AES is a block cipher, not a cipher. It's used per some operating mode. Among these

  • ECB without padding has the desired property that one can concatenate ciphertext fragments without decompression artifact, but is unsafe, and works only if the plaintext is an exact multiple of the AES block size (16 bytes).
  • CBC and CFB with IV prepended as ciphertext (which is usual) would do precisely what's reported: "when I decrypt 20 (concatenated ciphertext fragments) together it sounds like the original but with some clinky noise" because the IV (and perhaps some padding in the previous fragment) is misinterpreted as data, and inserts an error;
  • CTR or OFB would not recover from the error, and thus only the first 1/20 of the audio would be intelligible.
  • GCM or other authenticated mode would not output anything.

Is it possible using AES or another method to call my decrypt function on the concatenated 20 messages as one message and get the concatenated decrypted results?

Yes. One needs to take come precautions w.r.t. padding, but if the existing encryption procedure splits the data on some multiple of 16 bytes, there's nothing to change on encryption. Just remove from the output the extra data that corresponds to the inserted IV, and perhaps padding. That's merely 19 memory copy, over 19/20 of the data. It might save time, or not, depending on off-topic considerations.

For padding, the plaintext fragments should be aligned on multiples of 16 bytes (except for the last).

Encryption can be with padding (as most libraries do), but then one should either

  • Remove the last 16 bytes of each ciphertext fragment except the last before joining the ciphertext fragments; and remove the 16 bytes of IV at each of the 19 fragment frontiers in the output of decryption.
  • Remove the 16 bytes of data the padding generated (thus removing 32 bytes at each of the 19 fragment frontiers: 16 for padding of the previous fragment, and 16 for IV of the next one).

Alternatively, one can encrypt without padding, and manually pad the last plaintext fragment with zeroes, which for most compressed audio gets removed by the player, and for some uncompressed audio is silence.

$\endgroup$
1
  • $\begingroup$ Yes, it was CBC. Thank you for your response. The inefficient runtime was cause though by my naive calling of the "key scheduling" for each chunk of data. Now it is fixed and runs fast even though I have to decrypt each individual chunk. $\endgroup$ – A S May 4 at 11:03

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.