I implemented AES-CCM according to RFC-3610 and am wondering why the length of the additional authenticated data l(a) needs to be protected by the MAC.
Asked
Active
Viewed 918 times
0
-
This is more a question for [crypto](http://crypto.stackexchange.com/). You are welcome asking questions about implementing CCM here, but for crypto algorithm/mode design, please use another forum. You may get better answers too (although imichaelmiers seems to do a pretty good job at it). – Maarten Bodewes Apr 27 '12 at 23:47
1 Answers
1
Standard caveat: don't write your own encryption and use it. Use trusted libraries written by professional crypto people. There are ones for almost any language/ runtime you need or that should compile for it.
as to your question :
CBC-MAC by default only works on fixed length messages. If an attacker knows a tag t on message m and and t' on message m', they can forge a tag on a third message that was not actually sent. In fact this is
If you prepend the length, its safer, though you can still get messages that are prefix's of each other and run into a similar problem. Hence one of the reasons a nonce is also prepended.

imichaelmiers
- 3,449
- 2
- 19
- 25
-
Thanks for your answer. Unfortunatly it does not answer my question. Your first paragraph with the warning not to write own encryption is unnecessary. I specifically mentioned that I implement AES-CCM. Furthermore, my question is specifically on why the length of the additional authenticated data l(a) needs to be protected by the MAC. Your answer is only on additional authenticated data in general, which I do understand. Thanks anyway. – Netzoss Apr 27 '12 at 08:24
-
Clarification on why I needed to implement it myself: I only implemented the CCM portion. I do have an AES implementation but unfortunately, for the platform I am using there is no suitable CCM implementation - see question [Basic high performance data authenticity](http://stackoverflow.com/questions/9980043/basic-high-performance-data-authenticity). – Netzoss Apr 27 '12 at 08:38