Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

I have a file containing 16-bit samples and I want to encrypt it, but the proble

ID: 649417 • Letter: I

Question

I have a file containing 16-bit samples and I want to encrypt it, but the problem is that I need to be able to read any random 16-bit value from the file, and be to able to decrypt it, without reading larger (or surrounding) blocks. Because else it would require huge modifications to the device and driver.

It doesnt need to be very strong encryption, so I thought about just XOR-ing each 16-bit value with a another (fixed) value. But thats not really secure once the plain-text is known. And there are many samples with the value '0' at the start of the stream, so it would be easy to deduce the secret XOR value just by looking to the startblock.

Is there a similar method, that is almost as efficient and low-memory, but offers a little more security than my example above? The encryption may only take a few CPU cycles because its for an embedded MCU, however the decryption will be done using very fast CPU's.

Explanation / Answer

Any block cipher in CTR mode can be used to encrypt and decrypt data in arbitrary order.

Basically, to encrypt something in CTR mode, you use the block cipher to encrypt a simple sequence of values, like (1, 2, 3, 4, 5, etc.), and concatenate the results to produce a pseudorandom bitstream, and then XOR this "keystream" with the data you want to encrypt. Since you can produce any block in the keystream at any time just by feeding the appropriate counter value into the block cipher, you can easily decrypt the data in any order.

(Yes, you can even decrypt pieces of data smaller than a single cipher block with CTR mode, even down to a single bit. You do need to compute the keystream block by block, but you don't need an entire block of ciphertext to be able to decrypt it. If reading the ciphertext is much slower than block cipher encryption, this may be a useful optimization, and you can always cache the keystream block in case you need it again.)

The work needed for CTR mode encryption is basically the same as for decryption, and depends on the block cipher you're using. If you can find a usable AES implementation for your MCU, I'd recommend using it; it's a standard, widely used and well analyzed cipher. As they say, nobody ever got fired for using AES. If AES is too much for your MCU, you may want to look at specialized lightweight block ciphers like PRESENT instead.

Also note that CTR mode does not, by itself, protect message integrity