In my new challenge-project my server once upon a time is broadcasting an "onion" made of three layers encrypted with AES128 (ECB) - 16 bytes long over WiFi.

I am using a WiFi Beacon Frame, to transfer the Onion over the air.

The "Onion" looks more or less like the picture below

enter image description here

Each layer is encrypted with a different key. The keys to each layer are known only to the server and devices which are to decrypt them. Keys are made of the MAC address for simplicity.

  • The first layer is always a random 16b long string i.e "Hello World", encrypted with device 1 key
  • The second layer is the first layer encrypted with device 2 key
  • The third layer is the second layer encrypted with device 3 key

In order to decrypt the onion properly, the first broadcasted layer is 3, as we're decrypting backward.

Once the "Onion" is constructed, the server does broadcasts layer 3 over the WiFi Beacon Frame, and anyone who can listen to it can try to decrypt the data but only selected devices can decrypt it properly, as the layers are encrypted with their keys.

When each of them decrypts the layer it :

  • lets the server know over TCP/IP the hash of the decrypted value (confirmation)
  • takes down the 'layer'
  • broadcasts the rest of the onion back over the WiFi (Constructs a beacon frame).

Once all the layers are decrypted, the job is done.

The problem is that the devices have no option to confirm whether the decryption (key used) is good or not once decrypted, thus causing a lot of unnecessary traffic to the server with incorrect hashes (due to wrong decryption).


What should be done to allow devices to validate if the decrypted data is valid (thus the key is correct)?

Side note:

The ECB was used due to the simplicity of implementation, devices taking part in the decryption process are low-power sensors and had this cipher ready to use 'straight out of the box'.

  • 1
    $\begingroup$ Mac-then-encrypt, however, it seems you restrict yourself to 16-byte therefore not possible until the last layer. $\endgroup$
    – kelalaka
    Jan 23 at 22:09
  • $\begingroup$ @kelalaka thank you! What's the minimum i need (in bytes) to include MAC in each layer? $\endgroup$
    – PeeS
    Jan 23 at 22:11
  • 1
    $\begingroup$ It depends on what kind of probability you want. 8-bit 1/64 .... $\endgroup$
    – kelalaka
    Jan 23 at 22:13
  • $\begingroup$ Understood, i can go up to 64b per layer. Is there any specific MAC type i should choose ? $\endgroup$
    – PeeS
    Jan 23 at 22:16
  • 1
    $\begingroup$ As fastest, use BLAKE2 hash? You don't need authentication, right? Just integrity will be enough. $\endgroup$
    – kelalaka
    Jan 23 at 22:20

1 Answer 1


Since you need only validation you can simply use a fast hash function like BLAKE2 for your aim.

$$ c_0 = E_{k_1}(m_0) $$ then append the 64-bit (or more) BLAKE2 hash of ciphertext

$$m_1 = c_0\mathbin\|BLAKE2(c_0)\mid_{64}$$

$$ c_1 = E_{k_2}(m_1) $$ then then append the 64-bit (or more) BLAKE2 hash of ciphertext

$$m_2 = c_1\mathbin\|BLAKE2(c_1)\mid_{64}$$

$$ c_3 = E_{k_3}(m_2) $$

Now, release the $c_3$. When decrypted the client can check the hash. For a random key it will have $1/2^{64}$ probability to fit the appended hash. Note that when the $m_2$ is not correct the appended hash will not be the correct value, just a random value.

If you use CBC mode for the encryption (though it seems ECB is fine for your purpose), then you may benefit from the padding, too (ECB will also need). CBC mode always requires padding PKCS#7 padding. If the message is not decrypted correctly then the padding will fail (this is used in padding oracle attacks). There are false positives, too. Like with 1/256 probability the padding will be correct for an incorrect key. So integrity is better to approach to go.

Aside from hash, one can also use appending individual string per layer.

$$ c_0 = E_{k_1}(m_0) $$ then append $\texttt{Layer1}$ string. That is the fastest.

$$m_1 = c_0\mathbin\|\texttt{Layer1}$$


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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