Encrypt 8/16 bits binary codes into 16 bits binary code

[snoopy5376]

I have a 16 bits binary code. I would like to encrypt it to 16 bits binary code. I've done XOR encryption on it.
Example:
01101001 10100110 (message to be encrypted)
XOR 00100100 00000001 (2401 hex in binary)
-----------------------------------------------------
01001101 10100111 (encrypted message)

However, this could easily be decrypted by anyone. I would like to know is there any more complicated method of encryption that i can use? I've read on XTEA but it is for 128 bits. Any other encryption method that i can use? Thanks for the help.

[asmallri]

If you are encrypting a single 16 bit value as opposed to a series of values then your proposed encryption method is ok.

If you have a series of 16 bit values then you can use XTEA.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[temtronic]

ANY encryption method can be decrypted,even XTEA, DES,etc.(btdt) You don't say how the data is being transmitted or the quantity you're dealing with.That is important as it determines how much time($$$) you need to spend on 'protecting' the data.
Are you concerned about the interception of data between transmitter and receiver or after it's stored?

[snoopy5376]

i am going to transmit 16 bits binary. so the output of the encryption algorithm should be 16 bits binary. As what i understand, XTEA and DES do not produce 16 bits binary output, am i correct? XOR encryption is able to produce 16 bits binary output, however, i am asked to look for more complicated encryption method. any suggestion? thanks for the replies. :-)

[asmallri]

[temtronic]

The key is the KEY. The methodology of HOW the data is encrypted.My energy control systems have used 22 bit data for almost 3 decades and no one has been able to sucessfully hack into the system( yes, it has been tried..).
However, you haven't told us any details as to the PIC you're using, where or how this one 16 bit data is being accessed.You've asked a somewhat general question NOT what this forum has been created for.
Odds are it'll soon be 'locked' due to being 'off topic'.

[snoopy5376]

Thanks for your help.

This is the XTEA.c code from thread http://www.ccsinfo.com/forum/viewtopic.php?t=25933&highlight=xtea

[temtronic]

one way ...

Take your 16 bits of data, imbed them into known positions in the 8 bytes you will transmit as your 'XTEA data'. Upon reception, decode the XTEA data, recovering the 16 bits from your known positions and rebuild the original data.

It's up to you to decide if this is 'secure' enough for you and as I've already said not the way I'd do it.Heck, anyone reading this post can decode your code !!

[asmallri]

Another way without modifying the encryption logic is to replicate the 16 bit value (2 bytes) to produce a 8 byte value. Encrypt the 8 byte value, send the value to the remote site, decrypt and discard the last 6 bytes.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[asmboy]

because your data page is effectively just 16 bits per "message" - AND there may be a risk that an observer can TELL based on the time between packets that its only 16 bits -
The other commentators are quite correct in stating that it is not worth your while to encrypt - since a trivial brute force attack will break any repetitive use of simple algorithms. And suggestion to bulk up the data size with padding - amounts information hiding, a completely disrespected
technique used only by amateurs. And weak as can be too.

The only clear direction that offers any promise is the use of a MUCH longer hash key, ideally of some 16bit multiple ( my favorite is 131*16 bits )
which, after an initial sync word - you rotate by 15 bits for every 16 bits sent. However because it is NOT DES or RSA - it is still breakable - but not simply - even tho "eve" the eavesdropper may be able to tell you are sending only 16 bit complete messages.
Think of it as being close to a one time pad - BUT hampered by needing to be decoded with only that single key.

Really i've been amused by all this - thinking to myself
whats so precious about this data that you need to encrypt it in the first place ?? Trident Launch codes? Banking security ?
LOL -
Your post has ALL the hallmarks of a school project gone walkabout.

[temtronic]

Even DES is breakable...classic Intel (sorry not a PIC) document(80 something...described in detail how to create DES...If you 'read backwards' you can see how to decrypt.

For every lock there is a key...even mine though after almost 30 years no one has ever cracked it and it's only 22 bit data !

[Mike Walne]

You could try something based on a Pseudo Random Number Sequence Generator.

Start with a seed value for a PRNSG.
Get the PRNSG to produce a new key for each new code.
XOR your new code with the new key to get your cyphered code.

To decipher you use the same PRNSG and seed value as the coding.

PRNSG sequences repeat after a number of operations which depends on the generator.

You could try the CCS random number generator to get a feel for how it might work. The CCS version repeats after 2^15 - 1 operations.

Then you create your own PRNSG. A typical PRNSG is a shift register with feedback. By changing feedback location(s) you search for maximal length sequences. A maximal length sequence is 2^n -1 long for an n bit shift register. Not all shift register lengths can give maximal sequences, I believe there is no maximal length sequence for a 16 bit register.

Way back in the days of zilog Z80s, I have a vague recollection of experimenting with 63 bit shift registers.

Mike

[temtronic]

You could also 'borrow' the rolling code algorithm that Microchip uses for their RF devices as used in say 'garage door openers','car security systems'.

Amazing how much time can be wasted on 16 bit !!