TEA Encryption

[ivanenev]

Hi Everybody.

I'm new to PICs and I was wondering if somebody could help me with the following:

In circuit I'm using pic16f877 that writes 8 byte in eeprom 24lc512.
Everything works fine but I would like to encrypt the data before writing them to the eeprom.

I decided to use TEA algorithm because it takes only 240 words and 33 byte of RAM.
Here is some explanation about TEA algorithm (http://www.simonshepherd.supanet.com/tea.htm) and here is the code written in assembler, version 1.3 of TEA (http://members.tripod.com/~mdileo/cryptopic.html) including test program for 16f84.

So, my problem is that I don't understand assembler. Trying to use the instructions ASM....ENDASM at the beginning and the end of the program I couldn't compile even the test program (teatest.asm).

I would appreciate any help or piece of code you can give me.

Thanks in advance.

Ivan

P.S. Sorry but English is not my mother language.

[Dwayne]

Hello Ivan,

I know that this sounds crazy, but why bother with complex code for a encryption? Use up that RAM and Code space? All encryption can be broken, and the code of the encryption is someplace in that chip.

Instead of going through that mess, why not take advantage of the computers limitations?

For example....

Lets encript the following data.

Data var Byte
EnCryption var Byte
NewValue var byte

Data= "Hello World"
EncryptionCode="MySecret".



A way to think about it, is a byte can only go to 255 (FF) and starts all over again.

All you need, is two loops....

For s=0 to length of Data step 1
NewValue=Data[s]
For t=0 to length of EncryptionCode Step 1
NewValue=NewValue+EncrptionCode[t] + a changing Value
(that value can be the "s" in the For/Next loop)
Next t
'whala! NewValue is encrypted what do you want to do?

Next s 'get next value to encrypt.


And you do the opposite to Decrypt it.


Just a idea.....

Dwayne

[ivanenev]

Thanks for the replay Dwayne,

At the beginning I was thinking to use something like that you've suggested, just instead addition to use XOR.

For example:
......
For t=0 to length of EncryptionCode Step 1
NewValue[t]=NewValue[t] ^ EncrptionCode[t] + a changing Value
Next t

where NewValue and EncrptionCode are arrays.

Also the data can be packed before the encryption to make the thinks more complicated.

Just wonted to use any strong algorithm.... and I'm still trying :)


Ivan

[Dwayne]

Hello Ivan,

Ivan>>Thanks for the replay Dwayne,<<

You are very welcome.

Ivan>>At the beginning I was thinking to use something like that you've suggested, just instead addition to use XOR.<<

Thats another way how to do it... Not to complicated, yet usable.


Ivan>>Also the data can be packed before the encryption to make the thinks more complicated.<<

Yip!... How about PKZIP in a ASM program within a PIC chip <g>....Ok... I went off on a tangent here and headed backwards...


Ivan>>Just wonted to use any strong algorithm.... and I'm still trying <<


You are doing a great job.... Sometimes even the simplest of encryptions are the hardest to break...


Dwayne

[rastan]

hi, ive read your post with interest, and ive tried to encorporate dwaynes idea to encrypt informaition. problem is, im not quite as experienced at programming as you two guys, so could you possibly explain the idea behind encrypting informaiton with RAM?

and secondly, even though im working blind here ive tried to compile a version of encryption but it does not work :/

Data1 VAR BYTE
EncryptionCode VAR BYTE
NewValue VAR BYTE
s VAR WORD
t VAR WORD

Data1 = "1234"
EncryptionCode="MySecret".


For s=0 TO 4 STEP 1
NewValue=Data1[s]
For t=0 TO 8 STEP 1
NewValue=NewValue+EncrptionCode[t] + s
Next t
Next s

says something about not accepting
data1 = "1234"
doesnt like it
and NewValue=NewValue+EncrptionCode[t] + s
why?

thanks peeps

phil

[mister_e]

says something about not accepting
data1 = "1234"
doesnt like it
why?


Because you can't store more than 1 character in a variable...

If you plan to translate/encrypt data, you'll have to get it byte by byte using an array or the internal EEPROM of your pic.

easier and use less code space with the internal EEPROM if your PIC have one...
data @0,"My text to be encrypt"

and then after you just have to read EEPROM adress by adress


for Addr = 0 to 21
READ Addr,HeresOneCharacterToEncrypt
' do your encryption stuff here
next




and NewValue=NewValue+EncrptionCode[t] + s


because you didn't set EncryptionCode as a array
EncrptionCode var byte[21]

[rastan]

cheers man, but thats all gobledegook to me, have to read up on eeprom storage (never done it before).

over my head :D

phil

[mister_e]

cheers man, but thats all gobledegook to me,


gobledegook ? something like 'chinese for me' or else?

[rastan]

lol, yeah. dont know where that came from actually, possibly english, possibly more local. dont know :)

phil

[Dwayne]

Hello Rastan,

Rastan, in c/c++ I use a encryption code as a word. In Assembly (or with Micochips) it lacks the ability do do such, except without high overhead and usage of memory.

One of the oldest tricks in the book, is substitute a letter for a letter (just like a cryptocrypt in the newspaper. If you can give the reader the code to decipher it, then it is easy to "crack".

Now, lets make this one step easier yet...99.9999 percent of all code crackers give up pretty easily. If you get that .00001 percent person, you are just out of luck. (That is why they have EUA that say you cannot "reverse engineer" etc etc etc). (Who would want to reverse Engineer a 100 meg program?) Though I have to admit, I spent 2 months reverse engineering a program and cracking it, because it used a lazer spot on a disk for its security. The company wanted BIG bucks for a upgrade, and all I wanted to do, was to get our companies data off of their file structure into "FAT"/"DOS" TEXT format, to do our own programming and Information Technology. The week I finally got our info off their "format", was the week we trashed their thousands of dollars of programs, their thousands of dollar upgrades, and said "Good Bye". the system was called NIAWKA. I think they are still in business too. They had software that took the old WANG 2200 systems, created a special "Platter" on FAT disks, and made IBM machines think they are WANG 2200 machines. It worked very well. But I wanted to be fully DOS/FAT without anyones "imulator"

Now with that said, to do a cheapy for the spoof of the 99.9999 people...
two ways how you can do it.
1.

a=g
b=f
c=j
d=d
...
...

doing it this way, you will need a table with 255 table for a lookup. and you need to pass that table to the reader, to "reverse engineer" and make sense out of it.

The other way, is to add a certain "number" to your table... Lets say we pick the number "5"

1=1+5=6
2=7
3=8
.....
251=0
252=1
255=5

(notice when you went above 255, it started back to zero. Sine the highest number the variable can read is 255, it automatically rolls over for you! To "reverse engineer" it you just subtract 5.

"Hello World" with just "1" added to the hex value looks like this:
Ifmmp#Xpsme

For most people, that looks like garbage...At worse case senario, they will find the code in 254 tries

the code would like something like this:

Sentence ="Hello World"
code number var 1
for counter=1 to sentencelength.
Sentence[counter]=sentence[counter]+1;
next counter


Dwayne

[rastan]

ok good idea dwayne. ill give it a go.

thanks,

phil

[Dwayne]

Hello Rastan,

One other thing...(explaining the code word);
IN these pic chips, you pass a number (my last example uses the value 1).

Sometimes you may want to pass a code word.

What you can do, is a kind of CRC on that word, and pass THAT number.

Example:
CodeWord ="SecretWord"
PassingValue var byte;

PassingValue=0;
For counter=1 to CodeWordLength
PassingValue=PassingValue+CodeWord[counter]
Next counter

What this does, is add up each individual character in CodeWord.
if it goes above 255, it automatically rolls over to zero and starts over
again. When you get done adding up your characters out of your SecretWord, you will have a number (CRC) between 0 and 255.

Another (more complicated to some degree, but just as easy), is to
switch the hex numbers around...
$48 = $84
$12 = $21
....
...

But passing a number insures 254 different possible codes.

Dwayne