1

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

Maestro
  • 1,069
  • 1
  • 10
  • 16
  • 3
    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. – Thomas Mar 16 '15 at 09:04
  • @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 – Maestro Mar 16 '15 at 09:05
  • 3
    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. – CodesInChaos Mar 16 '15 at 09:51
  • Your first idea is basically a Vigenere cipher. Its security in modern understanding: None. – tylo Mar 16 '15 at 13:13
  • @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. – Maestro Mar 16 '15 at 14:11
  • @Muis Which cipher is cheapest depends on the hardware. I expect RC4 to be reasonably fast on most small CPUs, as long as you can afford the RAM to keep its state. It also has a relatively expensive key setup, especially if you drop the first 1000 bytes (which I strongly recommend), but that doesn't matter for a large file. – CodesInChaos Mar 16 '15 at 14:27
  • Since ARM Cortex M0 is a 32 bit processor and supports addition, rotation and xor, it should even be able to efficiently run ChaCha (possibly reduced to 8 or 12 rounds). – CodesInChaos Mar 16 '15 at 14:28
  • RC4 is probably faster than AES in your case – Vincent Mar 16 '15 at 15:55
  • This Q might be related: https://crypto.stackexchange.com/questions/24464/what-is-the-most-light-weight-crypto-thats-still-usefull – buherator Mar 17 '15 at 09:46
  • @CodesInChaos I picked RC4 because it looks so simple. So can you add your comment as an answer so I can accept it. – Maestro Mar 17 '15 at 18:51

2 Answers2

1

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.

Vincent
  • 966
  • 1
  • 11
  • 30
  • 1
    "I have an embedded device." – CodesInChaos Mar 16 '15 at 09:47
  • The OP is suggesting something similar to a Vigenère encryption, not Caesar. – CodesInChaos Mar 16 '15 at 09:52
  • I always get those mixed up. my bad you're right. – Vincent Mar 16 '15 at 09:54
  • 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. – Maestro Mar 16 '15 at 14:08
  • than don't encrypt it xD – Vincent Mar 16 '15 at 15:45
  • if you want something that is 'fast' would a hash algorithm in the mix do? http://crypto.stackexchange.com/questions/24088/using-hash-for-one-time-pad-key

    One of my fun hobby idea's might be enough for you. though i don't know if a Hash is too expensive in your case.

     – Vincent Mar 16 '15 at 15:53
  • I'm pretty sure GCM is the fastest mode+authentication with AES-NI. The instruction set has an instruction that makes the GHASH much faster to calculate, and CTR is no slower than CBC (with the bonus of no padding issues). – cpast Mar 17 '15 at 06:03
  • yes but he does not have the instruction set which makes cbc faster, and if it's just for encryption on the device there's no problem, decryption is a bit slow though. It does not show how fast GCM is on the ARM Cortex M0 but it does show CBC and ECB https://realtimelogic.com/products/sharkssl/Cortex-M0/ which is decent right? – Vincent Mar 17 '15 at 07:19
  • The Cortex looks pretty fast for AES, but I don't know the requirements. @cpast I'm pretty sure OCB beats GCM (and I certainly hope that this is not a defensive device). GCM may not be fast on embedded, but as the Cortex is 32 bit the performance could be better than the 8/16 bit counterparts. – Maarten Bodewes Mar 17 '15 at 17:36
  • @MaartenBodewes Its an Cortex M0 running at 12Mhz, so its not so fast. And I need to save battery. I was in doubt between RC4 and XXTEA and I picked RC4 now. It seems good enough. – Maestro Mar 17 '15 at 18:50
  • 1
    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. – Maarten Bodewes Mar 17 '15 at 19:25
  • @MaartenBodewes The max clock for a Cortex M0 is 48Mhz, and I underclocked 4 times. The device is a batterypowered sleeprecorder so it doesnt need to be fast as long as it can do its job. – Maestro Mar 18 '15 at 07:46
-2

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.

Alexey Vesnin
  • 226
  • 5
  • 7
  • 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. – Maarten Bodewes Mar 17 '15 at 17:37
  • Is TripleDES faster or slower than RC4?, because I picked RC4 now. – Maestro Mar 17 '15 at 18:50
  • 1
    @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. – Maarten Bodewes Mar 17 '15 at 19:23