I'm exploring ways of encrypting Intel hex files we send to customers for flashing onto an embedded device. The embedded processor itself has a built-in mechanism that prevents anyone from reading the contents of the flash memory unless you unlock it using a 128-bit password.
A trivial method I thought of to encrypt the contents of the hex file is to XOR its data fields with this 128-bit password. The embedded bootloader (which knows the password) would then XOR the incoming cipher text to recover the plain text before flashing it.
The hex files are several hundred kilobytes in size. Typically such a scheme is susceptible to a frequency analysis attack, but (according to Wikipedia) the success of such an attack is dependent on the ability to make assumptions about patterns in the plain text. I have two conflicting arguments with regard to this, and I can't decide which one is more accurate.
Since the underlying plain text is processor instructions one cannot make assumptions about repetition patterns.
Because the plain text consists of opcodes interspersed with operands for those opcodes, you're working with a finite set (the opcodes supported by this processor), this fact can be exploited to identify patterns.
Pertaining to the second argument, it is a CISC processor that supports several hundred instructions; some of these opcodes (parts of the opcode) vary depending on the operand. It is certainly not a small set we're talking about.
Is this approach flawed or does it make for reasonable encryption under these circumstances? (I realize the question is subjective, but I don't know how to make it more quantitative).
The password certainly does not have to be limited to 128 bits, but due to size concerns it'll always be several orders of magnitude smaller than the code being encrypted.
What if I were to introduce some heuristic where, depending on the data content, the password was first rotated before XORing with a given block of plain text?
Lastly, I'm open to other ideas of dealing with this situation as well.