XOR cipher
Sniper King
Posts: 221
I am developing a simple XOR encryption/decryption.· Attached is the code.· it isn't working right.· Any help would be cool.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Was it pin 11 or 26?· Hmmm....··I think the smell of smoke tells the whole story.· Must be 26.
Michael King
Application Engineer
R&D
Digital Technology Group
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Was it pin 11 or 26?· Hmmm....··I think the smell of smoke tells the whole story.· Must be 26.
Michael King
Application Engineer
R&D
Digital Technology Group
Comments
Key=MIKE
Message=This is a test
T XOR M
h XOR I
i XOR K
s XOR E
XOR M
i XOR I
s XOR K
... and so on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Was it pin 11 or 26?· Hmmm....··I think the smell of smoke tells the whole story.· Must be 26.
Michael King
Application Engineer
R&D
Digital Technology Group
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Was it pin 11 or 26?· Hmmm....··I think the smell of smoke tells the whole story.· Must be 26.
Michael King
Application Engineer
R&D
Digital Technology Group
I cant even post the results because the nature of the ASCii character are un reproducable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Was it pin 11 or 26?· Hmmm....··I think the smell of smoke tells the whole story.· Must be 26.
Michael King
Application Engineer
R&D
Digital Technology Group
byte[noparse][[/noparse]msg+i] rather than msg, since you want to do it by byte but msg I think does it by long since it can't tell the original size.
Also you can remove buf and write directly to emsg/dmsg, which is a good idea if msg is > 64 bytes.
While this is much more complicated than what you are trying to do, I have implemented blowfish (popular xor block cipher) for the Propeller. It is availible here: http://forums.parallax.com/showthread.php?p=714050
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
I wrote a DOS program back in the early 90’s that did this exact same thing. I probably still have the source code. In any event, what I was going to suggest is that you break down the steps. For example, the routines that adds 48 to each byte…try saving the output from that step before proceeding. When you get to the step of subtracting 48, save that data out as well and compare the two strings. Because you are taking multiple steps to an end goal there may be an issue in an intermediate step. For that matter, have you tried not adding/subtracting the 48? As for posting results, you can always attach a binary file if you can output to one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
PUB Encrypt(Key,Msg,Emsg) | z,i
z := 0
repeat I from 0 to strsize(msg)-1
byte[noparse][[/noparse]emsg+i] := (byte[noparse][[/noparse]msg+i] ^ byte[noparse][[/noparse]key+z])+48
if ++z == strsize(key)
z:= 0
byte[noparse][[/noparse]emsg+i] := 0
The XOR method as applied here is basically a stream cipher with a repeating key, the only way to make it stronger is to have a random byte stream as the key the same length as the plain text message.
This would implement a Vernan cipher AKA "one time pad" which is impossible to break as long as the key is random for each message.
Cheers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Was it pin 11 or 26?· Hmmm....··I think the smell of smoke tells the whole story.· Must be 26.
Michael King
Application Engineer
R&D
Digital Technology Group
I should point out that with a modern laptop doing some number crunching this type on encryption will take way less than an hour to break.
We have in the past done similar things in similar places and I would suggest that you should change the key on every location report.
Just a thought.
Here is a nice wikipedia article on the subject:
en.wikipedia.org/wiki/Stream_cipher_attack
Post Edited (Praxis) : 7/31/2008 5:10:16 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Was it pin 11 or 26?· Hmmm....··I think the smell of smoke tells the whole story.· Must be 26.
Michael King
Application Engineer
R&D
Digital Technology Group
Just a thought[noparse]:)[/noparse]
Just out of curiosity:
1. How long is a typical key with respect to a typical message?
2. How many messages are sent with a given key?
3. Is the key random characters, or a sequence of words?
4. How are the keys distributed?
5. What does a typical message look like? Just numbers (lat/long)?
Can you provide the forum members a group of encoded messages (using a typical key) to crack? 'Better to have it broken here and know about so you can strengthen it than to have the bad guys do it and not know about it!
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
If that is the case then a reverse engineer of the XOR'ed string will be easy to achieve as the NMEA string length more or less stays the same length, the problem is compounded by the regular spacing of the field delimiters namely the commas.
Cheers
An example, If it is an NMEA string then because of the field delimiters its easy to separate out the lat/lon fields.
Now we know that these are numeric values only, in the format of Lat: DDMM.mmmm and Lon: DDDMM.mmmm.
Even a brute force approach checking for a numeric result will be fairly quick.
Just a thought.
Post Edited (Praxis) : 7/31/2008 6:18:09 PM GMT
Why don't you post an example of one your encrypted (using the posted spin code algorithm) GPS messages for use to try and decode ?
Add:
Another problem that comes to mind is key synchronization, that would require some type of public key implementation.
Post Edited (Praxis) : 7/31/2008 7:34:33 PM GMT
Many good ciphers use Xor, its dependent on how you generate and distribute the key. if you have a good scheme for key generation then xor is good.
I have been retired for a decade or so. The rules for the military used to be quite explicit that all codes, cyphers, and keys (the system and the items) had to be approved or provided by the National Security Agency. We got slapped for using our own.
I couldn't agree more, albeit without the benefit of your boots-on-the-ground experience. This whole thread worries me, since lives could be at stake; and I don't consider the matter closed by any means. I hate to use the word "cavalier"; but, under the circumstances, a lack of qualified vetting would certainly put the proffered algorithm in that category.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
My point exactly.
That was 1998. 10 years ago. The machine would be both less expensive today and cheaper.
Your encryption method is MANY orders of magnitude weaker than DES. And it suffers from the fact that the plaintext format is partially known: We know that it's a GPS string and that it's in ASCII format. That narrows down the characters to at most 96. Someone cracking this now just needs to brute force a 4 byte string and discard anything which has bytes outside this region. Then, from these, it cracks again, until its narrowed down the list to the point where a human can find something which looks correct.
THIS IS VERY EASY. On a modern PC, cracking it shouldn't take more than a minute.
DO NOT OVERESTIMATE HOW SECURE YOUR ENCRYPTION IS. ALWAYS OVERSPECIFY TO SOMETHING STRONGER THAN WHAT YOU NEED.
I CAN TELL YOU FIRST HAND THAT SECURITY IS NOT EASY.
Then again, if this is going out for any millitary purpose, then it shouldn't be accepted anyway. All the millitaries I know of require that a cryptographically secure encryption system be used.
The "sand box" application would be I guess for civilian contractors, keep in mind that the old information is also useful as it gives a history of locations, routes etc.
I would suggest that you use the Blowfish cipher as posted by Paul Baker.
Just a thought.
XOR codes are very easily recognized as such and very easily cracked.
Got a 256 bit key? Whatever it is, it might as well be 256 zeroes or ones.
If your phone uses Code Division Multiplexing (CDMA), you can be eavesdropped even if
you have a continuous True Random Number Generator as your code key.
Common Knowledge: Code Division Multiplex signal = (Your Voice) XOR (Pseudo Random Number Generator)
1.· The addition of 48 to the ascii cypher byte has been changed to a random number.
2.· The position in the key where the· encryption starts·from is also random.
3.· The key is 64 bytes long and are·values from 0 to 254. These keys are randomly generated.
In my tests sending the same message for over an hour to my computer for processing, I never saw the same encrypted message twice. My software captured every message and compared.
The messages being sent are letters, numbers and a few operators.· I will post 20 encrypted strings of the same message for you all on monday and lets see what happens.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Was it pin 11 or 26?· Hmmm....··I think the smell of smoke tells the whole story.· Must be 26.
Michael King
Application Engineer
R&D
Digital Technology Group