default key?

[jblazeg]

Whats the default key, when not calling aes.setkey(...,32)?

[rweather]

The key will probably be whatever random garbage was in the key schedule memory prior to constructing the object. Which is unpredictable. Since the constructor is almost always followed by a call to setKey(), I judged it to be inefficient to clear the schedule in the constructor. It is wasted clock cycles.

You can call clear() after construction to set the schedule to all-zeroes if you need the memory to be initialised, but be aware that an all-zero schedule may not correspond to any specific AES key with the default AES128, AES192, and AES256 classes.

The default implementations of AESTiny128, AESTiny192, and AESTiny256 will set the key to all zeroes by calling clear() but I wouldn't rely upon it.

I would suggest explicitly calling setKey() with an all-zeroes key to initialise the object with a known default if you need that behaviour for some reason.

[jblazeg]

Would there be a way to print the key? I know it could potentially be a security issue, but since it is embedded the risk is really small.

[rweather]

In theory yes. The first part of the key schedule is the key itself. For example, from AES256.cpp:

// Copy the key itself into the first 32 bytes of the schedule.
uint8_t *schedule = sched;
memcpy(schedule, key, 32);

You could add a getSchedule() function to AESCommon to return the pointer to the schedule and then print from that. Would only work with the default implementation however. Doing this with the ESP32 version would be problematic, which is why I wouldn't want to add this to the official version of the library.

Also, this may not work with hardware-accelerated modules in the future, only the current implementation. Accelerated modules often have a way to set the key but not to retrieve it afterwards.

[jblazeg]

That worked, great. Thank you!