# Encrypting serialized data

If I want to encrypt structured data composed of key-value pairs of strings, would it be an advantage to use an encoding that stores keys, values and their lengths, and is padded with random numbers, rather than JSON that always starts with {", ends with "} and predictably contains strings enclosed in "..." separated by ,?

I'm thinking of encoding the data like this:

R1
LK1 K1
LV1 V1
LK2 K2
LV2 V2
R2


(where Rn are random numbers of fixed size obtained from a CSPRNG and L.. are the lengths of the data that follow)

instead of:

{ "K1": "V1", "K2": "V2" }

• AES with CBC, CTR is CPA secure. – kelalaka Nov 26 '20 at 15:20
• (Note that modern cryptography offers security regardless of underlying plaintext structure) – SEJPM Nov 26 '20 at 15:22
• PS you might be interested in learning about binary encoding formats, specifically CBOR and Protocol Buffers. Don't reinvent the wheel (again). – Maarten Bodewes Nov 26 '20 at 15:45
• Yeah, that's probably a good idea. Also, beware that the size of the ciphertext may still reveal information to adversaries, it's something often forgotten by cryptographers and therefore, users of cryptography (it's explained in chapter 1, assumed in chapter 2 and forgotten by chapter 3, basically). – Maarten Bodewes Nov 26 '20 at 16:13
• @MaartenBodewes, would padding the plaintext with a random string of variable size help against this? The string would just be ignored, but the I'm thinking the size of the resulting ciphertext will be random. – Hashi Oki Nov 26 '20 at 16:16

## 1 Answer

If I want to encrypt structured data composed of key-value pairs of strings, would it be an advantage to use an encoding that stores keys, values and their lengths, and is padded with random numbers?

Generally, no, this is not a good idea. A semantically secure cipher uses an IV or nonce (number used once, a unique number in a statically sized encoding) that randomizes the ciphertext in combination with the key used. There is therefore no need to randomize the data input (the "message") itself.

It very much depends on the mode of operation if the randomization of the message will actually fully randomize the data in the first place. In case of CBC mode a random block with the block size of an IV could be used as an alternative to a random IV. However, it would not really differ from using an IV in the first place; it will actually cost you one additional block to encrypt for no reason at all. On the other hand, if you consider the more modern CTR mode then the key stream will just be XOR-ed with the random input, and it won't influence the rest of the plaintext / ciphertext message. The random data would just be overhead without offering any benefit.

Modern authenticated modes just require a nonce, randomized or not. GCM mode for instance requires a 12 byte nonce. You can safely prefix the IV or nonce to the ciphertext (as the size is commonly known or configured in advance). Note that CBC mode requires an unpredictable (i.e. randomized) IV.