0
$\begingroup$

I want to encrypt a JSON file while exposing its interface (the name of the object fields) in clear text.

Since this exposes part of the content of the file, my guess is that an attacker could use this to hack the encryption key.

Are there encryption methods that can circumvent, or at least be safer for cases like this?

I am mostly convinced that knowing part of the content of an encrypted file can make attacks easier, but I do not know if there is a technical term for such conditions or how to evaluate if some algorithms are safer or not. So far I am specially interested if using aes-192-cbc or gpg would be OK.

$\endgroup$
5
  • 3
    $\begingroup$ This is known as Known-Plaintext Attack (KPA) and even in the ECB mode, no AES is secure: Is it possible to find the key for AES ECB if I have a list of plaintext and corresponding ciphertext?. One can use the CBC as long as there is no padding oracle attack case and guarantee that nonce is randomly generated. $\endgroup$ – kelalaka Aug 9 '20 at 11:11
  • 2
    $\begingroup$ @kelalaka I think you meant “no, AES is secure”, not “no AES is secure”. But actually, while AES itself is secure, it's only secure to encrypt 128-bit messages. AES-ECB, which allows encrypting multi-block messages is not secure against known-plaintext attacks. For example, if $P_1 \ne P_2$ are two data blocks and the adversary knows that $\mathsf{AES\_ECB\_Enc}(P_1||P_2) = C_1||C_2$, then the adversary knows the decryption of $C_2||C_1$. $\endgroup$ – Gilles 'SO- stop being evil' Aug 9 '20 at 19:53
  • 2
    $\begingroup$ Use a standard protocol instead of rolling your own. $\endgroup$ – Gilles 'SO- stop being evil' Aug 9 '20 at 19:54
  • $\begingroup$ @Gilles'SO-stopbeingevil' yes it should be "no, AES is secure". Yes, multi-block security is a big issue for ECB. thanks $\endgroup$ – kelalaka Aug 9 '20 at 19:58
  • 1
    $\begingroup$ @Gilles'SO-stopbeingevil' interpreting "hack the encryption key" as actually extracting the key, AES even in ECB mode should be secure in this (laughably weak and in probably every case insufficient) sense. This follows from standard PRP security. $\endgroup$ – Maeher Aug 10 '20 at 8:55
2
$\begingroup$

If you use any reasonably standard modern encryption scheme, there's no need to worry. Ideally you should be using authenticated encryption like AES-GCM.

In modern cryptography we generally require an encryption scheme to at least have IND-CPA security to call it secure. IND-CPA stands for "indistinguishability under chosen plaintext attacks".

This security notion is defined as a game between a challenger and the attacker. The challenger chooses a key for the encryption scheme. The attacker can then query any ciphertext of their choice to the challenger and receives an encryption that plaintext. Eventually, the attacker outputs two challenge plaintexts $m_0,m_1$, the challenger flips a random bit $b$, and gives an encryption of $m_b$ to the attacker. The attacker can continue to make queries as above and eventually has to guess which message was encrypted. In an encryption scheme that is IND-CPA secure an efficient attacker can essentially do no better than guessing randomly.

The attack you are worrying about is much much weaker than what we consider the minimal security required of an encryption scheme. Any sane implementation of AES-CBC, AES-CTR or a modern stream cipher like Salsa/Chacha would be secure in this sense. (Even 3DES in CBC or CTR mode is fine, though horribly slow.)

In practice malleability of ciphertexts is often an issue, which is why it's generally advised to use "authenticated encryption", which prevents any modifications of the ciphertext.

$\endgroup$
1
  • $\begingroup$ This answer should add the AES-GCM security notion, too. $\endgroup$ – kelalaka Aug 10 '20 at 17:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.