0
$\begingroup$

I'm looking at the AES-CMAC RFC and I found somehow counter-intuitive the way test vectors are used in the test code.

Let's look at the key K

K 2b7e1516 28aed2a6 abf71588 09cf4f3c

The least significant octet is 0x3c, right? If this is true, why it becomes key[15] and not key[0] in the test code?

 unsigned char key[16] = {
     0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6,
     0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c
 };
$\endgroup$
1
  • 3
    $\begingroup$ Have you checked the notations and conventions section of the AES specification? $\endgroup$
    – fgrieu
    Nov 25, 2020 at 12:35

1 Answer 1

4
$\begingroup$

Keys for AES are not numbers; they are defined as bits / octets (or bytes). They therefore do not have a "least significant octet", they just consist of octets. So the same order from lowest index (left) to highest index (right) is being used.

As common the bits are indexed from right to left though; this is probably due to humans having some trouble converting hexadecimal digits otherwise. It just shows that humans are terrible at thinking in little endian.

The exact ordering is specified in the AES specification as mentioned by fgrieu int he comments.

$\endgroup$
1
  • $\begingroup$ Ok, I think I understand. The key of the example is just a sequence of 128 bits that starts with 00101011 and ends with 00111100, so when this is represented as an array of 16 bytes, the first byte key[0] is set to be 00101011, which is now intuitive. Thanks! $\endgroup$
    – Šatov
    Nov 25, 2020 at 15:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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