There is a JSON array like this:

    "date": "28.08.23 10:52",
    "type": "text",
    "data": "card number including expiration date and CVC"
    "date": "29.08.23 10:52",
    "type": "text",
    "data": "bank password in the form admin:password"
    "date": "30.08.23 10:52",
    "type": "text",
    "data": "coordinates where I buried the corpse."

This array is then subjected to JSON.stringify(json) and encrypted with the AES-128-ECB algorithm.

What I end up with is this:


Now we simulate a hacking attempt.

We don't know what's stored in the value of the keys, but we do know:

  • that it was JSON;
  • that each block contains the keys "date", "type" and "data";
  • that most likely the type field has the value text, but not for sure;
  • It is also possible to know what is specified in date.

Does this knowledge make hacking easier in any way?

I realize that using an IV would solve everything, but I don't know where and how to store it because it has to be different and classified every time.

I want to store important information on the Internet in encrypted form so that I can easily access it. That is, it's a page on GitHub pages, where I share encrypted data and a password field. I enter the password and this data is decrypted using JavaScript. Everything happens on the client side, which is my side.

This is all very convenient up to the point where I only have a "password" field. For example, in JavaScript the Web Crypto API (native support) is excluded from the AES-ECB methods, which can exist without iv because they don't consider it secure enough. I can use the Crypto-JKS library which has ECB, but there is a security issue here.

Hence, I have to look towards GCM or CBC where IV is a prerequisite for decryption. I can't memorize IV, but then I don't know where and how to store it.

  • $\begingroup$ "I can't memorize iv, but then I don't know where and how to store it." - typically, it is stored with the ciphertext $\endgroup$
    – poncho
    Aug 30 at 12:10

1 Answer 1


This array is then subjected to JSON.stringify(json) and encrypted with the AES-128-ECB algorithm.

That is: what's shown it's stripped from whitespace except in strings, leading to ≈274 characters encoded per ASCII into as many bytes. This then is encrypted with the AES-128-ECB algorithm and some padding mode into 18 × 16 = 288 bytes, then converted to text per Base64 encoding to 384 characters.

Does this knowledge make hacking easier in any way?

Depends on definition of hacking.

It does not help towards recovering the AES-128 key, which would effortlessly allow decryption of everything.

However, the fact that AES-ECB is used does allow some level of attack on confidentiality. Like depending on the length of the fields, there is a possibility that an adversary can tell with certainty that some dates are identical (if they are), or detect that some consecutive bytes appear in two "data" fields.

For an illustration, AES-ECB encrypt then Base64 these 65 characters, e.g. with this.

the old password has expired, we will thus burn the old password.

The output will be on the tune of the following, where the first 21 characters repeat 43 characters later. An observer can ascertain that the first 16 bytes of the plaintext repeat 32 bytes later, which is something about the plaintext, when the theoretical goal of encryption is to hide everything about the plaintext (except it's length).


More importantly, AES-ECB encryption allows shuffling 16-byte segments of the deciphered plaintext simply by shuffling the corresponding ciphertext segments, including from earlier ciphertexts. This can be a vector of attack, depending heavily on context.

For example, if the message conveys a new password, it's realistic that adversaries could modify the ciphertext so that the decryption results in a message that conveys a different password that they know, because it's a known field in the same message. That's all without knowing the key, even if the key is used for that single message.

To avoid such attack on integrity, if we stick with symmetric cryptography, a recommendable thing to do is to use an authenticated encryption mode like AES-GCM.

I can't memorize IV, but then I don't know where and how to store it.

Storing the Initialization Vector and Authentication Tag is easy: basically they are in or along the ciphertext. It can be internally handled by the encryption and decryption APIs, or added on top if not. Typically the IV is generated randomly on encryption and put at start of ciphertext, the AT is generated as a byproduct of encryption and put at end of ciphertext. The decryption extracts the IV, use it for decryption, extract the AT, check it (if invalid, it's critical that the deciphered plaintext is discarded).

We can use a RNG to generate the IV. For AES-GCM, the requirement is that it's a (e.g. 12-byte) value unique per encryption session of at most 64GiB. That's something a TRNG or proper /dev/urandom does (but a PRG as defined in cryptography does not). If there was any difficulty generating a (most likely) unique IV for each encryption, we can use AES-GCM-SIV.

The Base64 encoding of the ciphertext produced by encryption and it's decoding before decryption can apply to IV and AT as well in the same operation.

  • $\begingroup$ You really confused me when you said "and the amount of whitespace formatting". I encrypted via ECB "1 1 1 1 1 1 1" and got "3/muipHQV5Hgeo3U3AxgTA==", then "2 2 2 2 2 2" -> "K4/JGWZRZWXSO5kMYyFW8g==", then "3 3 3 3 3 3 3" -> "shCoxeCJjydsn5ILbYMtrw==" and at the end "3 3 1 3 3 3" -> "Ys9HCkznVx3taR4Ti8UHqA==". From the resulting data I can't see a pattern, in any of the variants. Although in all cases it's 5 digits separated by 4 spaces. I can't imagine how to decipher this data at all. $\endgroup$ Aug 30 at 19:38
  • $\begingroup$ I don't understand anything about the presence of iv either. It seems more like a time defense. Something like when the Enigma cipher was cracked, but with a significant delay. In my case the whole cipher is available at once and there is no need to compare new and old message, as you can compare parts of one big one, as they have the same structure. $\endgroup$ Aug 30 at 19:38
  • $\begingroup$ @accountnujen: I fixed some things in my answer, like your encryption process actually strips whitespace, which I had missed. I added some example that you can try of the consequence of using ECB. The CBC or CTR modes and their Initialization Vector are there to make this king of things impossible. The GCM mode and it's Authentication Tag are there to protect against intentional alteration of the deciphered message. Countless application designers thought they did not need these, and got burnt. Don't repeat their mistake. $\endgroup$
    – fgrieu
    Aug 31 at 7:22
  • $\begingroup$ You'll pardon my intrusiveness, but I need to fully understand all the risks. I encrypted the JSON specified in the question using AES-GCM 256. The attacker knows the array structure (keys) but does not know the values. Knowing the keys, is it possible to perform a "known-plaintext attack"? Just if you google "AES-GCM attack", there are several mentions of "known-plaintext attack" on this site. I see that you are an expert and your answer is very important to me $\endgroup$ Oct 23 at 1:27
  • $\begingroup$ Here's the code to encrypt the data: codepen.io/accountnujen/pen/yLGaxWG . IV and salt are placed at the very beginning of the cipher. I encrypted the JSON array and got this: crfZ6va9qpl8SndNHzNLeSrGTYliqcWaCrOY/vpRH1C2Gp0Nq6NOV6R6cAfolgI/3RWs7lQbFrcrSz7skdQ1UdS2AZPreYUwaNnWfWHc/uf6D/j7mkGGoU949kBZp8SmNdC3ch/tcItFJ3Zj1ZuinuZkXW1vzmsdCLnL83oqSsaLuOX5RTUK+Wn18wWoL7QOP0nOhvVPzBiUPV5Xp2zbJrZIg4ee . What are the chances of decryption if the attacker knows that the structure looks like this: [{"date":"?","type":"?","data":"?"}] $\endgroup$ Oct 23 at 1:30

Your Answer

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

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