0
$\begingroup$

Developing a wireless home security system based on STM32M0 µcontroller, I'm currently looking for the best way to manage encryption/authentication.
For information, the STM32M0 has an AES hardware acceleration module with main modes.

So , I looked first for AES-GCM as AEAD, but there's too much overhead: my data is about 16 bytes , maybe 4 of additional data, and there's 12 bytes IV, and 16 bytes Tag.
I want to avoid that IV / Nonce to reduce frame size.

So here's the intended scheme:

  • Encrypt plaintext (that contains a UNIQUE 32bits counter for frames) using AES.
  • Append additional data without encrypt it
  • Use a MAC without IV/nonce (like CHASKEY, optimized for embedded)

This way I have to use 2 keys , one for AES and one for the MAC. I guess the second can be derivated from the first.

Is this scheme is secure enough for the purpose ?

Improve this question
$\endgroup$
4
  • $\begingroup$ Is the data that needs to be encrypted about 16 bytes or exactly 16 bytes (max)? $\endgroup$
    – SAI Peregrinus
    Jan 31, 2018 at 14:45
  • $\begingroup$ Not exactly 16 . But most of the frames will be short ones. But some other frames could be larger. The max size will be 64 bytes for the total , including additional data and tag $\endgroup$
    – SadE
    Jan 31, 2018 at 15:28
  • $\begingroup$ Since your ciphertext can be longer than 1 block (16 bytes) you'll need to use a mode of operation that takes a nonce anyway. So there's no getting away without one and keeping security. $\endgroup$
    – SAI Peregrinus
    Jan 31, 2018 at 15:55
  • $\begingroup$ But a unique counter IN an encrypted AES-CTR cypher does not act as a nonce ? $\endgroup$
    – SadE
    Feb 2, 2018 at 7:34

1 Answer 1

Reset to default
1
$\begingroup$

my data is about 16 bytes , maybe 4 of additional data, and there's 12 bytes IV, and 16 bytes Tag. I want to avoid that IV / Nonce to reduce frame size.

Encrypt plaintext (that contains a UNIQUE 32bits counter for frames) using AES.

So this means that you already have a 32-bit unique value per-message. If you can guarantee it to be unique across all messages under any specific key, then you can use these 32 unique bits, padded with 0s to 96 bits as your IV for AES-GCM. Or you can construct the IV as your 32-bit unique value + 64 bit of randomness per message, which is transferred explicitely.

If you want to optimize even further (at the cost of security, mind you!), you could use a mode that allows tag truncation (do not truncate AES-GCM tags!), such as AES-CCM. There you would use a similar IV setup as above and additionally you could truncate a few bytes of the authentication tag. The calculation is simple: Let $r$ be the maximal risk you are willing to take that a forged message slips through. Let $e$ be the maximal number of times you output "invalid" for a given key on invalid ciphertexts. Then your tag should have length $l$ at least $l\geq \log_2(e/r)$ (this does not apply to AES-GCM). For more information, have a look at appendix B of NIST SP800-38C (PDF).

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thanks for the answer. In fact most of the message will have a size of about 16 bytes , maybe a little more. And some with variable length field. To suppress the risk of replay attack , a timestamp will be automatically joined in all data. Thanks for the idea to use additional data as a nonce (with always keep in mind to use an unique one). but this counter is a part of the protocol : it's used to manage ack and retries frames for each node. So , Isn't a bad idea to put it in clear ? $\endgroup$
    – SadE
    Jan 31, 2018 at 15:26
  • 1
    $\begingroup$ As long as you don't mind the counter to be visible to anybody then sure thing, you could put it in the clear (Maarten commenting here, not SEJPM). $\endgroup$
    – Maarten Bodewes ♦
    Feb 1, 2018 at 12:11

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.