XXTEA and BTEA encryption decryption

[Cyberman]

Currently I'm looking at these for short message data that is byte aligned. These algorithms appear to like double word aligned data. They also appear to be sensitive to endianess in some circumstances. I prefer to implement encryption in an encapsulated system (IE data goes in data goes out no data is exchanged outside the system unless it's encrypted) myself.

Right so WHATS my problem? Well my data is byte aligned and TEA XXTEA and BTEA are all 4 byte aligned (and and endian sensitive as a consequence).

So PC's are little endian biased and what I have is big endian oriented in it's double word arithmetic. My guess is the encryption overhead burden might make things even slower with my communications (but hey it's not like we are transferring huge amounts of data here we are talking tiny stuff at best).

The other problem is the data to be encrypted is definitely not double word aligned, it's byte aligned. Messages are packets of data from 3 to 23 bytes in length. 7 bytes overhead and remaining data is the payload. Messages can be as short as 3 bytes (with only 1 byte to be encrypted) so suggestions on how to encrypt a single byte packet so that it decrypts correctly?
My guess is this is not possible so that means very short messages have to use something else (for encryption)

The packet structure consists of type data (if any) length and source/destination inform with a 8 bit CRC at the end. I suppose I can arrange it so that source / destination information and if word aligned data is encrypted? Hmmm it's kind of messy.

Anyhow thoughts? I was considering mixing the encryption usage based on the size of the packet. (IE byte oriented encryption on sections that are not double word aligned and on sections of data that are double word aligned the btea on that).

The data does not require STRONG encryption just enough to make it difficult for someone to send bad data and it be interpreted as a real message and god only knows what happens after that.

Cyb

 

[smcd]

With it being byte aligned data and small payloads, maybe a block cipher isn't the best route? Looked into RC4? (Yes, it's weak - but it's easy and fast)

 

[Cyberman]

With it being byte aligned data and small payloads, maybe a block cipher isn't the best route? Looked into RC4? (Yes, it's weak - but it's easy and fast)

Interesting, I had seen it listed with TEA. I'll give this a look, I had thought of using a pseudo random number generator for a roaming key in the encoding however this can get messed up by system noise (how do you resynchronize the key with an error is the problem). Thanks that could work. Cyb

 

[Cyberman]

Problems with arc4

Well synchronization is about the same issue with arc4. Because it uses a pseudo random sequence (not original that's for certain) where it starts is both good and bad. Knowing the key isn't useful at times with arc4 encryption. LOL

So perhaps I can use an error record as a resynchronization request from the server. IE get error (the error might be read able but no likely) one can know it's an error but not WHAT the error was because of the leading and trailing data (might even be able to guess what it was that was sent based on the trailing data) hmmm anyhow on error reception a specific sync event is done and packets are set from the client starting and a given point in the PSRG.

My thought at least. I don't need strong just need something that keeps people from screwing with the data and causing trouble.

Cyb

 

[ihearpixels]

My thought at least. I don't need strong just need something that keeps people from screwing with the data and causing trouble.

Looked at other symmetric ciphers like RC6?

 

[Cyberman]

Looked at other symmetric ciphers like RC6?

Well since it wasn't selected for AES and this is for a commercial product and I can't volunteer the company I work for too a license with RSA
------------------------
Licensing

As RC6 has not been selected for the AES, it is not guaranteed that RC6 is royalty-free. As of January 2007[update], a web page on the official web site of the designers of RC6, RSA Laboratories, states the following:
"We emphasize that if RC6 is selected for the AES, RSA Security will not require any licensing or royalty payments for products using the algorithm". The emphasis on the word "if" suggests that RSA Security Inc. may now require licensing and royalty payments for any products using the RC6 algorithm. RC6 is a patented encryption algorithm (U.S. Patent 5,724,428 and U.S. Patent 5,835,600).
---------------------------

If it were non commercial the FBI still would be on my tail so ... either way it would be a problem.

Duh I neglected another issue, I do not have unlimited resources (remember embedded systems are quite humble by comparison to what PC's have). RC6 requires a considerable amount of resources compared to an arc4 class implementation.

Cyb

 

[smcd]

If you had an area to sacrifice, would protocol overhead, processing power, or memory usage be least detrimental?

 

[Cyberman]

If you had an area to sacrifice, would protocol overhead, processing power, or memory usage be least detrimental?

Ahhh yes specifications help, unfortunately I don't have any. Nope the boss said "no budget no specs ... has to use what we have" a bit of a pain. I can't use an ARM (preferred processor but over kill by the bosses view) for example (we have no dev kits for that at work although I myself have a bunch of arm stuff at home go figure).
Right now a 8 bit processor with 32K flash and 1 1/4 K of RAM so arc4 is relatively easy to implement. RC6 based cipher and AES (requires 4K plus 32 bit arithmetic) algo's are a bit more than it can handle in anything close to a timely manner.

As I said I prefer ARM but hey it is what it is I guess.

Cyb