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.


1 Answer 1


The encryption scheme seems to be:

  • re-use an existing 128-bit secret, originally used to unlock a read-prevention mechanism, as the 128-bit key;
  • split the plaintext (data to protect from prying eyes) into 128-bit blocks;
  • XOR each block with that 128-bit key.

That approach is flawed. Two cardinal mistakes are made:

  1. Use XOR with a keystream that repeats.
  2. Reuse a secret (and what's worse, without any level of derivation).

Due to 1., if there is anything guessable in the plaintext (such as, a block with like 40 consecutive 00h bytes, or an ASCII string of about that size that appears in the user interface, or a code sequence from a common library), the 128-bit secret is easily recovered, and the confidentiality of the whole plaintext is lost; that's kid's play, really. Same (for more effort and data, like a some kilobytes) if some characteristics of the plaintext are known (like instruction set and compiler), enabling attacks like frequency analysis.

Due to 2., the above attack also reveals the 128-bit key used to unlock a read-prevention mechanism, ruining it. The confidentiality of both earlier and later code is lost.

Why not use true cryptography? See this answer, especially the final paragraph and what it links to.

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?

If the rotation is the same for each block, that will not help at all to protect the confidentiality of the ciphertext; the above attacks guessing the key work unmodified. That helps, even so slightly, to protect the secret used to unlock a read-prevention mechanism (because it is now mildly different from the one used in a futile attempt to protect the code's condifdentiality).

If the rotation varies with each block (say, as the low 7 bits of block number), it might help slightly w.r.t. the confidentiality in some cases, but in many others it harms significantly: for example, knowing that rule for rotation, and on the sole assumption there exist a contiguous zone of few kbyte where 90% of the bytes have their bit 7 of zero (with about random distribution of those that do not), it is now trivial to recover the whole key by frequency analysis; then the whole plaintext. What's needed here (if for some reason it was indispensable to use the same secret for two uses) is a derivation mechanism, not security-by-obscurity.

Also, are we talking password, or key? That's not the same thing. A key is assumed chosen at random, a password is not.

  • $\begingroup$ Well, if you manage to decrypt the hex file, the processor's read-prevention is worthless anyway, since everything that the attacker wants is in the hex file. But you raise a very good point about the presence of ASCII strings. There are a few (very small percentage compared to the rest of the code) embedded strings. There may also be sections with consecutive 00h bytes. Does rotating the key make any difference, or is it merely a nuisance that can be overcome easily? $\endgroup$
    – Praetorian
    Commented Mar 6, 2013 at 18:53
  • 2
    $\begingroup$ Like he said, why not use true cryptography? It actually solves the problem, and doesn't just put a band-aid over the gaping wound that is XOR with a repeating key stream. $\endgroup$ Commented Mar 6, 2013 at 18:54
  • $\begingroup$ @StephenTouset I'm not against using a real cryptographic solution; this idea has very little cost of implementation, which is why I'm considering it. If it is fundamentally flawed (and it seems to be) I'll opt for some other encryption methodology. $\endgroup$
    – Praetorian
    Commented Mar 6, 2013 at 19:00
  • $\begingroup$ Everywhere I've used the word password I'm referring to the 128-bit key (which will be randomly chosen); I wasn't aware of the distinction. Thanks for pointing it out. $\endgroup$
    – Praetorian
    Commented Mar 6, 2013 at 19:05
  • 2
    $\begingroup$ @Praetorian: My suggestion here would be the ChaCha cipher. It's easy to implement (even in very little code space), very fast, only requires slightly more than 64 bytes of RAM and has top notch security. The author recommends a 256-bit key, but I think unless your facing a serious threat of the NSA throwing billions of dollars at computing your secret key (while they could use a $5 solution) a 128-bit key will probably do fine (and is supported by ChaCha). $\endgroup$
    – orlp
    Commented Mar 6, 2013 at 22:48

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.