1
$\begingroup$

Let's say we have a billion short individual json files with same regular structure: {"name": "<name>", "id": <id>}. Each file is individually encrypted with some crypto algorithm (symmetric or asymmetric). The cryptanalyst has all the billion files, and additionally knows public key that generated the billion individual encrypted files (in case the algorithm was asymmetric). So the two questions are:

  1. Is the application of encryption flawed (less secure) in this case?

  2. Are there some strong and standard PGP algorithms more vulnerable than others in this case? Does the availability of a billion short and similar jsons make deciphering private key (asymmetric) or password (symmetric) more likely?

  3. Is there a way to make this encrypted dataset more secure?

Note: There was a previous question asked here which could be seen as a prelude to this one, or this one it's corollary.

$\endgroup$

1 Answer 1

0
$\begingroup$

Is the application of encryption flawed (less secure) in this case?

It should not.

  • It's the goal of any modern encryption algorithm that it remains safe in the question's situation, unhindered by the billion ciphertexts: modern ciphers withstand Known Ciphertext attacks.
  • That's even if the attacker knows the original plaintext/JSON for each ciphertext (except for one they are trying to decipher#): modern ciphers withstand Known Plaintext attacks.
  • That's even if the attacker can get any plaintext of their choice encrypted: modern ciphers withstand Chosen Plaintext attacks.
  • That's even if the attacker can get any ciphertext of their choice decrypted (except for one they are trying to decipher#): modern ciphers withstand Chosen Ciphertext attacks.

Are there some strong and standard PGP algorithms more vulnerable than others in this case?

Every algorithm in GPG (an open source implementation of OpenPGP) is believed to resists at least Known Ciphertext, Known Plaintext, and Chosen Plaintext attacks, at least at time of release; and I don't recall any attack on that.

The situation is not as clear for Chosen Ciphertext Attacks. Most GPG algorithms (with exceptions including Twofish) resists CCA since about 2000, but it's possible to disable that protection; and combined with some plugin external to GPG and the tower of babel that a modern PC is, that can compromise security. See this, and linked references in the answers.

Is there a way to make this encrypted dataset more secure?

If you are sure that the size of the plaintext leaks no information, it's enough to correctly use modern crypto. Correct use most often imply authenticated encryption (that most GPG encrpytion algorithms aim to provide, with the same exceptions as above), and sometime digital signature (that GPG optionally provides).

I doubt that's the case here, though: it seems to matter that it can be distinguished the ciphertext for name Nu from the ciphertext for name Wolfeschlegelsteinhausenbergerdorff, and few if any common cryptographic algorithm protect against that.

In situations where size of the plaintext/JSON must be kept secret, the simplest and safest option is to make all plaintexts the same size, by padding to some maximum size. Since it's already bowed to a JSON format, another size increase might be tolerable. If the encryption is over the JSON (as would be the case for GPG), it's enough to add whitespace at the end or the JSON, or an extra field in the JSON. If the encryption is within the JSON on individual fields, then each of these fields must be padded and something may have to remove that padding.


# or get any intel about the original plaintext/JSON, except for it's size (it's not a standard assigned goal for encryption to hide the plaintext size).

$\endgroup$
1
  • $\begingroup$ Adding white space to JSON has the advantage that the intended recipient will not have to know about it at all and still everything (decryption and processing the unencrypted message) works just fine. $\endgroup$
    – gnasher729
    Mar 10 at 15:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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