View previous topic :: View next topic |
Author |
Message |
snoopy5376
Joined: 27 Feb 2012 Posts: 3
|
Encrypt 8/16 bits binary codes into 16 bits binary code |
Posted: Mon Feb 27, 2012 4:38 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Mon Feb 27, 2012 4:55 am |
|
|
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!! |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9172 Location: Greensville,Ontario
|
|
Posted: Mon Feb 27, 2012 6:31 am |
|
|
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? |
|
![](templates/subSilver/images/spacer.gif) |
snoopy5376
Joined: 27 Feb 2012 Posts: 3
|
|
Posted: Mon Feb 27, 2012 10:12 am |
|
|
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. :-) |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Mon Feb 27, 2012 10:19 am |
|
|
snoopy5376 wrote: | 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. :-) |
You can modify XTEA to work on 16 bits BUT
If you are only encrypting a 16 value and are using the same key for each 16 bit value then there are on 65536 unique values. If the base 16 bit value has an expected profile, eg. a temperature value, and has a well know structure, for example the upper 4 bits are typically zero, a brute force attack could be used to crack the key. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9172 Location: Greensville,Ontario
|
|
Posted: Mon Feb 27, 2012 10:37 am |
|
|
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'. |
|
![](templates/subSilver/images/spacer.gif) |
snoopy5376
Joined: 27 Feb 2012 Posts: 3
|
|
Posted: Mon Feb 27, 2012 10:38 am |
|
|
Thanks for your help.
This is the XTEA.c code from thread http://www.ccsinfo.com/forum/viewtopic.php?t=25933&highlight=xtea
Code: |
/*************************************************************/
/* */
/* XTEA - eXtended Tiny Encryption Algorithm */
/* */
/* Written by: Aurelian Nichita */
/* Compiler: CCS PIC C Compiler 3.242 */
/* Contact: nicksubzero@yahoo.com */
/* Source: http://en.wikipedia.org/wiki/XTEA */
/* */
/* */
/* Benchmark (one encipher/decipher cycle, 8 bytes) */
/* */
/* - PIC 16F877, 8 MHz, 32 iterations, */
/* ROM 776 bytes, RAM 26 bytes, time required 10.0175 ms */
/* */
/* - PIC 18F452, 32 MHz, 32 iterations, */
/* ROM 1296 bytes, RAM 30 bytes, time required 2.008 ms */
/* */
/* Code is optimised for size, RAM use and speed, */
/* it's 17% to 25% faster than the original XTEA code. */
/* It even fits in an 12F675, with quite some space left! */
/* */
/*************************************************************/
/* Number of iterations.
32 is ample, 16 is sufficient,
as few as eight should be OK for most applications. */
const signed int8 XTEA_ITERATIONS = 32;
/* The Golden ratio */
const unsigned int32 XTEA_DELTA = 0x9E3779B9;
/* Starting sum for decryption */
const unsigned int32 XTEA_DEC_SUM = 0xC6EF3720;
/* Enciphers 8 bytes using a 16-byte (128-bit) key.
"in" and "out" are arrays of two int32's,
"key" is an array of four int32's. */
#separate
void xtea_encipher (unsigned int32 * in,
unsigned int32 * out,
unsigned int32 * key)
{
unsigned int32 v0, v1, x, y, sum = 0;
signed int8 n = XTEA_ITERATIONS;
unsigned int8 i;
v0 = in[0]; v1 = in[1];
while(n > 0) {
x = v1 << 4;
y = v1 >> 5;
x ^= y;
x += v1;
i = make8(sum, 0); i &= 0x03;
y = sum + key[i];
x ^= y;
v0 += x;
sum += XTEA_DELTA;
x = v0 << 4;
y = v0 >> 5;
x ^= y;
x += v0;
i = make8(sum, 1); i >>= 3; i &= 0x03;
y = sum + key[i];
x ^= y;
v1 += x;
n--;
}
out[0] = v0;
out[1] = v1;
}
/* Deciphers 8 bytes using a 16-byte (128-bit) key.
"in" and "out" are arrays of two int32's,
"key" is an array of four int32's. */
#separate
void xtea_decipher (unsigned int32 * in,
unsigned int32 * out,
unsigned int32 * key)
{
unsigned int32 v0, v1, x, y, sum = XTEA_DEC_SUM;
signed int8 n = XTEA_ITERATIONS;
unsigned int8 i;
v0 = in[0]; v1 = in[1];
while(n > 0) {
x = v0 << 4;
y = v0 >> 5;
x ^= y;
x += v0;
i = make8(sum, 1); i >>= 3; i &= 0x03;
y = sum + key[i];
x ^= y;
v1 -= x;
sum -= XTEA_DELTA;
x = v1 << 4;
y = v1 >> 5;
x ^= y;
x += v1;
i = make8(sum, 0); i &= 0x03;
y = sum + key[i];
x ^= y;
v0 -= x;
n--;
}
out[0] = v0;
out[1] = v1;
}
|
how should i modify it?[/code] |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9172 Location: Greensville,Ontario
|
|
Posted: Mon Feb 27, 2012 12:47 pm |
|
|
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 !! |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Mon Feb 27, 2012 2:13 pm |
|
|
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!! |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Mon Feb 27, 2012 7:41 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9172 Location: Greensville,Ontario
|
|
Posted: Mon Feb 27, 2012 7:50 pm |
|
|
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 ! |
|
![](templates/subSilver/images/spacer.gif) |
Mike Walne
Joined: 19 Feb 2004 Posts: 1785 Location: Boston Spa UK
|
PRNSGs |
Posted: Tue Feb 28, 2012 2:16 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9172 Location: Greensville,Ontario
|
|
Posted: Tue Feb 28, 2012 4:00 pm |
|
|
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 !! |
|
![](templates/subSilver/images/spacer.gif) |
|