Join Log in
Score:2
avatar Crypto

Encryption with AES128 (ECB) and Key validation

cn flag
PeeS

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).

Question

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'.

211
0 + 0
kelalaka avatar
in flag
kelalaka
Mac-then-encrypt, however, it seems you restrict yourself to 16-byte therefore not possible until the last layer.
1
Reply
cn flag
PeeS
@kelalaka thank you! What's the minimum i need (in bytes) to include MAC in each layer?
0
Reply
kelalaka avatar
in flag
kelalaka
It depends on what kind of probability you want. 8-bit 1/64 ....
1
Reply
cn flag
PeeS
Understood, i can go up to 64b per layer. Is there any specific MAC type i should choose ?
0
Reply
Paul Uszak avatar
cn flag
Paul Uszak
You use the terms WiFi and radio interchangeably. THIS IS DANGEROUS. Encrypted radio transmission is illegal in the UK and US and most other countries. Citizens have no right of privacy on the air waves :-(
0
Reply
cn flag
PeeS
@PaulUszak - Ok, to be clear it's WiFi - i am not using anything else than a WiFi standard and the 'Onion' is broadcasted with a 802.11 beacon frame.
0
Reply
kelalaka avatar
in flag
kelalaka
As fastest, use BLAKE2 hash? You don't need authentication, right? Just integrity will be enough.
1
Reply
cn flag
PeeS
@kelalaka that is correct, all i need is integrity! Thank you very much for the input
0
Reply
Score:2
kelalaka avatar Crypto
in flag
kelalaka

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}$$

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.