# Is my XTEA encryption key safe if I publish my firmware both as plain text and encrypted?

https://github.com/nyholku/diolan-plus2

the actual XTEA code is here:

https://github.com/nyholku/diolan-plus2/blob/master/fw/xtea.asm

It is not my code but to me it looks like it uses 16 byte key and 64 iterations and seems to be pretty much equivalent to the wikipedia XTEA C-implementation.

Now my questions is, is my encryption key safe if I publish my firmware both as plain object code i.e. plain text and encrypted?

The firmware size if max 48kB out of which several kilobytes at the end will be 0xFF.

How about if over the years I publish number of ( <50 ) such plain text / encrypted text pairs?

I've read from the interweb that this should be safe but because the subject is so complex I would like to make sure I don't make a rookie blunder.

• How do you plan to keep the key XTEA_KEY secret? It's going to be right in the bootloader. – fgrieu Jul 19 '17 at 20:09
• the bootloader is programmed by me to the chip PIC18F45K50 which has fuses that can be set so that the code cannot be read back. As it is single chip I think that part of the solution is pretty safe. – nyholku Jul 20 '17 at 5:37
• I second Maarten Bodewes that there is not strong fear to have that the key could be recovered from plaintext/ciphertext pairs. I would fear extraction of the key from the bootloader e.g. by glitching the power supply during reset to make the CPU believe that the security "fuse" (probably some Flash/EEPROM memory bit) is not blown, then using the built-in debug port. And, independently, abusing the protocol/mode of operation using XTEA as a building block; is that described anywhere? I can't make an interesting answer without this. – fgrieu Jul 20 '17 at 11:34
• The bootloader/host protocol is here: usb-pic.org/bootloader-commands – nyholku Oct 4 '17 at 12:44
• This describes commands, like BOOT_WRITE_FLASH, but not a protocol. The later page leads to an encoder application, but the link to its source code is broken. What I see is not sufficient to determine if there is integrity, and leaves it doubtful that the protocol is secured against power loss during loading. Sorry, I can't say better than XTEA probably not being the weakest link. – fgrieu Oct 4 '17 at 12:49