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$
  • 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 '15 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$ – Muis Mar 16 '15 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$ – CodesInChaos Mar 16 '15 at 9:51
  • $\begingroup$ Your first idea is basically a Vigenere cipher. Its security in modern understanding: None. $\endgroup$ – tylo Mar 16 '15 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$ – Muis Mar 16 '15 at 14:11
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$
  • 1
    $\begingroup$ "I have an embedded device." $\endgroup$ – CodesInChaos Mar 16 '15 at 9:47
  • $\begingroup$ The OP is suggesting something similar to a Vigenère encryption, not Caesar. $\endgroup$ – CodesInChaos Mar 16 '15 at 9:52
  • $\begingroup$ I always get those mixed up. my bad you're right. $\endgroup$ – Vincent Mar 16 '15 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$ – Muis Mar 16 '15 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 '15 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$
  • $\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 '15 at 17:37
  • $\begingroup$ Is TripleDES faster or slower than RC4?, because I picked RC4 now. $\endgroup$ – Muis Mar 17 '15 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 '15 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.