I wanna make my own "way" of encrypting separate messages. And I want it to have the least possible size overhead while being completely encrypted (hide msg counter). Here's my current idea:

  1. we exchange some symmetric key K, along with random 32-bit counter start position
  2. for every message:
    • p1 = first 12 bytes of payload, p2 = the rest of payload
    • enc_header = aes_ecb_encrypt(K, counter || p1)
    • IV = some_secure_hash(K || counter)
    • enc_data_with_mac = aes_gcm_encrypt(K, IV, p2) // or chacha20+poly1305
    • result = enc_header || enc_data
  3. Every message increments counter by one. Before counter overflows we prepare new K, then use it after overflow, then as soon as receiver receives message encrypted with new key, he forgets old one.

As result, every message contains only 4+16 (counter+MAC) additional bytes and everything including counter is encrypted so only sender and receiver know what data is hidden.

Yes, this explanation is quite simplified. I hope this is enough to understand the idea. The main question is about using ECB mode this way. Just tell me why described algorithm is bad. Also, does random counter start position make this scheme more secure?

  • 2
    $\begingroup$ Don't call it ECB. ECB is a stupid concept that should be abolished, along with the entire conceptual framework of ‘block cipher modes of operation’. Just call it AES alone, since you're only doing it on a single block anyway. $\endgroup$ – Squeamish Ossifrage Apr 16 at 14:45
  • $\begingroup$ Why not start the counter at zero, increment it at every message on the sending and receiving end, and just use vanilla AES-GCM? Then you don't have to include it in the message at all; if the network might reorder packets a little, the receiver may have to keep a small buffer of messages but that's all. $\endgroup$ – Squeamish Ossifrage Apr 16 at 14:46
  • 1
    $\begingroup$ The random initial counter doesn't affect anything here, but the pseudorandom choice of AES-GCM nonce (‘IV’) makes for a nonzero probability of collision which destroys security; if you just used the counter directly as the nonce, that probability would be zero. $\endgroup$ – Squeamish Ossifrage Apr 16 at 14:47
  • $\begingroup$ Forgot to mention that these encrypted messages would travel over network and some of them could be lost. Or reordered. Like @SqueamishOssifrage said. So we need some counter for that. And thanks for note about pseudo-random nonce. Another idea is to exchange nonce the same way we exchange K and then use nonce+counter as IV for AES-GCM. $\endgroup$ – user67520 Apr 16 at 14:57
  • 1
    $\begingroup$ I should add: if you just used the counter + 1 directly as the nonce, that probability would be zero; otherwise the input AES(counter || p1) might collide with the internal AES-CTR stream used in AES-GCM. $\endgroup$ – Squeamish Ossifrage Apr 16 at 15:02

Your Answer

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

Browse other questions tagged or ask your own question.