1
$\begingroup$

I have an embedded device. It produces larges files (200 MB). I want the device to encrypt the file before writing to disk, so I gave them all a 16-byte random key.

How can I transform the large file with the small key, with the least amount of CPU?

If I XOR the data with the 16byte key, its almost good enough. But it will show repeated patterns from which you can distract the key (for example if the input is 16 zeroes), but can I make it better without sacrificing on performance?

AES on my device

$\endgroup$
10
  • 3
    $\begingroup$ XORing the data with a 16-byte key is not nearly good enough... unless your file is made up of random data that kind of encryption is very easy to break. $\endgroup$
    – Thomas
    Mar 16, 2015 at 9:04
  • $\begingroup$ @Thomas The data are brainwave signals, so they are pretty random, And I know its not fool proof, but it must be the best it can be given the restrictions. Can I not shift the XOR array one position to the right after each XOR for example? That would be a simple improvement $\endgroup$
    – Maestro
    Mar 16, 2015 at 9:05
  • 3
    $\begingroup$ If you don't need a lot of security, you could try RC4. It shouldn't need a lot of CPU, but it needs about 300 bytes of RAM for its state. Drop the first 1000 or so bytes of output to avoid the worst biases. There is also a whole field of lightweight cryptography, but I'm can't recommend any particular algorithm. $\endgroup$ Mar 16, 2015 at 9:51
  • $\begingroup$ Your first idea is basically a Vigenere cipher. Its security in modern understanding: None. $\endgroup$
    – tylo
    Mar 16, 2015 at 13:13
  • $\begingroup$ @CodesInChaos If RC4 is more light-weight than AES, I will accept your answer. I also find some other algorithms (LED, PRESENT, Piccolo) but I dont know how they compare to RC4, and I dont want to do a whole comperative study. $\endgroup$
    – Maestro
    Mar 16, 2015 at 14:11

2 Answers 2

1
$\begingroup$

Use AES-128, the instruction set in most CPU's (AES-NI) speeds up the encryption and does not put to much load on your CPU. I would use CBC but there might be better mode operations for encrypting files. Also don't forget to use a MAC.

Using a one time pad (OTP) is nice but what you're doing is not an OTP it's more a Vigenère cipher. If you were to use OTP the key should be as long as the file which requires you to store a (approximately) 200MB key.

Thanks @CodesInChaos I missed the "I have an embedded device", but than it's not a CPU it's a MCU (most likely) even than, AES is designed to be fast on any platform so i would still give it a try, just see how much it takes i think you'll be surprised as to it's efficiency.

Take a look at the list of validated AES implementations, see if there's something which resembles your embedded device.

$\endgroup$
12
  • 1
    $\begingroup$ "I have an embedded device." $\endgroup$ Mar 16, 2015 at 9:47
  • $\begingroup$ The OP is suggesting something similar to a Vigenère encryption, not Caesar. $\endgroup$ Mar 16, 2015 at 9:52
  • $\begingroup$ I always get those mixed up. my bad you're right. $\endgroup$
    – Vincent
    Mar 16, 2015 at 9:54
  • $\begingroup$ It's an ARM Cortex M0, so I may be able to find a AES implemenatation, but I want to save battery on the device as much as possible and security is not so important. $\endgroup$
    – Maestro
    Mar 16, 2015 at 14:08
  • 1
    $\begingroup$ 12 MHz? That's horrible, there are smart card chips that are able to run at 150 MHz! Battery powered or any other tiny power supply, I'm sure. $\endgroup$
    – Maarten Bodewes
    Mar 17, 2015 at 19:25
-2
$\begingroup$

In your case I'd recommend you to try TripleDES, maybe with a paired ARM MCU - it's cheap and fast enough... Try to take a look at STM chips, I used them before and I have a very good recommendations due to price/perfomance. Also you can try to implement DES physically if you have a hi-speed requirement in your device's spec list.

$\endgroup$
3
  • $\begingroup$ Bad idea. Triple DES is usually slower than AES, and if you go for a hardware implementation, you might as well make it AES too. $\endgroup$
    – Maarten Bodewes
    Mar 17, 2015 at 17:37
  • $\begingroup$ Is TripleDES faster or slower than RC4?, because I picked RC4 now. $\endgroup$
    – Maestro
    Mar 17, 2015 at 18:50
  • 1
    $\begingroup$ @Muis It's slower than AES and way slower than RC4. ECRYPT II looks at different stream ciphers, you could check a few papers from them. RC4 could be good enough as long as you heed the precautions. $\endgroup$
    – Maarten Bodewes
    Mar 17, 2015 at 19:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.