Is XTEA still my best option?

TinyCLR OS
1

Hi All,

I need to encrypt files (on a PC) roughly 0x400000 in size and then decrypt on the SitCore device. I implemented XTEA with a single pass, and this roughly takes 1.5 min on SitCore to decrypt. (TinyCLR Preview 5). RC4 takes 6 min (lol)

I know the H7 used doesn’t have any hardware accelerated cryptography. Is XTEA still the best option for my use case?

TIA

2

interested, but 1.5min like too long. Is there any way to optimize. Can we have a piece of code so we can try quickly?

does that include load 4MB from SD/USB?..

3

I do not think we have XTEA on TinyCLR 2.0, only RSA (a much stronger algorithm) Cryptography

So, how are you using XTEA?

It is possible we may add other cryptos in the future, depending on commercial demands.

Welcome to the community.

4

He build in his c# application, I think ?

5

Aha! That is why it takes a while. With native implementation it would take seconds.

@HiddenUser why not try RSA?

6

All,

Yes, the XTEA is implemented in C#, and is setup to stream from the SD card as the decryption is occurring. Please see the example files attached below.

My understanding of RSA is that it is asymmetric encryption which is computationally expensive and you are limited by the key size to how much data you can encrypt. Therefore, if the TinyCLR framework only accepts a 2048 bit key ((2048 - 384) / 8) + 37 = 245 bytes.

In my use case, I need to operate on up to 0x550000 bytes, which ruled out RSA. Though, maybe my implementation/understanding is incorrect.

Download the example here: Dropbox - File Deleted

Look forward to your feedback

7

Then xtea is good for now. When we add it naively in the future, your 1.5 minute will become 10 second :grin:

8

Why did you load single 4 bytes. For 4MB if you read by this way it take too long.

if no external RAM, you can read 4-8K or 10K then decrypt
Also when decrypt, why do you split to 2 small 4byte buffer?

and, use Array.Clear instead of filling zero to array.

9

and, use Array.Clear instead of filling zero to array.

Even I don’t see the reason that you need to fill zero to this array every time decrypt the block. The array is always filled with new data before decrypte, isn’t it?

10

When I did initial testing (like preview 2 I think), reading the file into heap took substantially longer. (Which is why I choose to stream/decrypt at same time) However, with today’s release, its down to 6 seconds to read the file into RAM, and then proceeded with decryption.

TEA/XTEA works in 64 bit block sizes, hence why I was working with two 4 byte buffers. I removed the array initialization :grimacing: (memset habit lol)

With those changes (mostly reading it into ram/heap) I have it down to ~60sec, which is acceptable to continue with the project. Hopefully XTEA makes it’s way into native one day :thinking:

Updated Code: Dropbox - File Deleted

Thanks!

11

sweet, but I still see your code still read from stream 4 bytes, isn’t it?

hence why I was working with two 4 byte buffers

I mean why don’t you use one array 8 bytes ?

I see you use 2 buffer uint, then use bit converter to convert one array 8 bytes. Too much work. it is very slow.

12

I was adhering to the demonstrated implementation in public domain.

void decipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) {
    unsigned int i;
    uint32_t v0=v[0], v1=v[1], delta=0x9E3779B9, sum=delta*num_rounds;
    for (i=0; i < num_rounds; i++) {
        v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum>>11) & 3]);
        sum -= delta;
        v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);
    }
    v[0]=v0; v[1]=v1;
}

I will investigate refactoring this to use a single array to be more micro friendly.

Thanks for your input. This is exciting.

1 Like