1

Say one encrypts multiple plain text blocks with same IV but different keys using AES-256-CBC, can one infer concatenated ciphertext block boundaries through digital forensics?

Example

Plain text block 1: foo

Plain text block 2: bar

Ciphertext block 1: <Buffer 88 65 7f 9f 7b 9d 47 51 21 cc 22 c0 2a 9e 69 57>

Ciphertext block 2: <Buffer a5 96 21 5b ed f6 e1 3b f7 7a fb 3e b4 f4 c0 4f>

Concatenated ciphertext: <Buffer 88 65 7f 9f 7b 9d 47 51 21 cc 22 c0 2a 9e 69 57 a5 96 21 5b ed f6 e1 3b f7 7a fb 3e b4 f4 c0 4f>

Concatenated ciphertext encoded to Base64: iGV/n3udR1EhzCLAKp5pV6WWIVvt9uE793r7PrT0wE8=

From “Concatenated ciphertext encoded to Base64”, can one infer boundaries of “Ciphertext block 1” and “Ciphertext block 2” without keys?

Reference implementation

import { createCipheriv, createDecipheriv, randomBytes } from "crypto"

const algorithm = "aes-256-cbc"


const sharedIv = randomBytes(16)


const fooSecret = "foo"
const fooKey = randomBytes(32)
const fooCipher = createCipheriv(algorithm, fooKey, sharedIv)
const fooEncrypted = fooCipher.update(fooSecret)
const fooBuffer = Buffer.concat([fooEncrypted, fooCipher.final()])


console.log(fooBuffer)


const barSecret = "bar"
const barKey = randomBytes(32)
const barCipher = createCipheriv(algorithm, barKey, sharedIv)
const barEncrypted = barCipher.update(barSecret)
const barBuffer = Buffer.concat([barEncrypted, barCipher.final()])


console.log(barBuffer)


const concatenatedBuffers = Buffer.concat([fooBuffer, barBuffer])


console.log(concatenatedBuffers, concatenatedBuffers.toString("base64"))
```
sunknudsen
  • 199
  • 8
  • Is the threat model that the attacker doesn't know the cipher and is attempting to determine block length? This wouldn't normally be a concern, since you would assume the attacker knows the full algorithm. There are only so many common block sizes, so it's pretty guessable without any analysis. – bmm6o Sep 15 '22 at 23:41
  • Remember, even the decrypter (as a key owner) without any extra information, can decrypt almost all blocks ( an error on ciphertext can affect at most two blocks ( see an image here). So, what other kind of information do you have? – kelalaka Sep 16 '22 at 08:30
  • Note that the decryptor doesn't need the boundaries, they need to decrypt from the last to the beginning and make sure that the previous block is not padding by the previous key... – kelalaka Sep 16 '22 at 08:34
  • Hey @kelalaka, threat model involves an attacker knowing shared IV (in plain text) and concatenated ciphertext (last line of reference implementation) but no keys… can attacker infer concatenated ciphertext block boundaries through digital forensics? – sunknudsen Sep 16 '22 at 09:42
  • @bmm6o The attacker would know reference implementation (hence cipher), have shared IV (in plain text), concatenated ciphertext (last line of reference implementation) but no keys… What I mean by block boundaries is inferring where fooBuffer starts and ends and same for barBuffer breaking plausible deniability. – sunknudsen Sep 16 '22 at 09:44
  • If I'm not missing something, one cannot. The problem of the owner of the data needs to keep the boundaries. hard to remember for them or is is encrypted somewhere... – kelalaka Sep 16 '22 at 10:42
  • @kelalaka What if boundaries of each data block are encrypted in the form of headers using same shared IV but different keys? One could then iterate through headers ciphertext, extract and decrypt header block and use boundaries to decrypt associated data blocks. See https://github.com/sunknudsen/blockcrypt/blob/master/src/index.ts. – sunknudsen Sep 16 '22 at 12:48
  • It is a possible way, but not in your case, so I've skipped it. Is this a part of CTF? You may also look at the failure of Veracrypt Hidden Volume – kelalaka Sep 16 '22 at 14:28
  • @kelalaka “Is this a part of CTF?” No, I am developing an open source encryption scheme with plausible deniability by design and want to make sure scheme is solid. Would love your help! I believe community could greatly benefit from Blockcrypt. I am not aware of an other project that scratches that itch. – sunknudsen Sep 16 '22 at 15:09

1 Answers1

1

Intuitively, this is secure against a passive attacker (that is allowed to choose the plaintexts) since both ciphertexts look like random gibberish and one cannot tell where one gibberish ends and another gibberish starts.

Formally, you should think about AES as random permutation. Let $n$ be the block length of the ciphertext concatenation. The probability that the ciphertext concatenation contains a block collision is less than $\frac{n^2}{2^{128}}$. Conditioned on there being no collision, the ciphertext concatenation is a just a sequence of $n$ distinct randomly chosen blocks.

Applying a base64 encoding is irrelevant since an attacker is free to apply that as well, it does not affect our conclusion about the ciphertext concatenation.

erth
  • 113
  • 4