Here's Blowfish (I don't know where Hootie is)
Paul Baker
Posts: 6,351
In order to understand the encryption algorithm Blowfish, I ported the reference code into Spin. The algorithm has been verified through test vectors. Current execution speed for initialization is just over 1 second. Each encrypt/decrypt function takes just under 2 ms to execute for a block size of 64 bits (2 longs). I'll likely port it over to assembly the next time I'm bored to see how fast I can get it to run. I hope someone will find the object useful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Comments
But where is that list???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 3/8/2008 12:20:09 AM GMT
This is an excellent and interesting app for the Propeller. I'm wondering, though: does your impetus for understanding the algorithm have anything to do with code protection on the Prop II?
-Phil
@Phil thanks, yes that was the impetus to looking into this stuff. I don't know if this algorithm will be used especially since the initialization process is so slow. Currently I'm envisioning a hub based Encryption block which can be aquired by a cog via a hardwired lock and will continue to own it until released (this is to protect the S-box and P array values from being accessed by other cogs). It would perform 1 encrypt/decrypt per hub access. Then upon release, all S-Box and P array values would be wiped before being availible to other cogs. This way the encryption algorithm can be used by user programs as well without compromising the security of the EEPROM code. This is all thought fodder, so it should not be infered that this is what will be done. I'll also be studying AES/Rijndael for computational speed comparisions, but I will also have to look at how exactly AES is restricted for foreign sale (and if it would be possible to step it down to 64bit to circumvent restrictions).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 3/8/2008 12:54:46 AM GMT
Well maybe it is not OT. On the current propeller there is no way of protecting anything in the hub except by encrypting it (and this only prevents someone from reading it not modifying it). So if you want to do encryption than it has to be done completely in the cog (blowfish may fit, I don't know enough about it) or only allow trusted code to run. i.e. If you allowed loading of programs like DOL than you wouldn't be guaranteed protection.
Possibly a greater concern would be the laws of other countries regarding the possession and use of strong encryption. It used to be that France did not allow the use of any encryption, and many other countries had quite strict rules as to what their population could and could not use. A lot of this may have changed in recent years also, especially with the formation of the EU and all the various and sundry trade agreements. Quite a minefield, it is.
All of these use encryption of one form or another. Were they not allowed?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am 1010, so be surprised!
EDIT:· Here's a newer source.· It looks like they did change the law in France.
http://en.wikipedia.org/wiki/Cryptography#Legal_issues_involving_cryptography
Post Edited (Beanie2k) : 3/8/2008 5:25:33 AM GMT
I'm not sure about it's relative security to other algorithms, but for a really small algorithm, look at XXTEA. Theres a reason TEA stands for Tiny Encryption Algorithm [noparse];)[/noparse]
http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm
I once analysed a file system where they used
SUM(fn[noparse][[/noparse] i ]) MOD 1024, where 'fn' contained the filename
as a function to optimize the population of 1024 tables...
This makes me still smile...
Unless you only want to compress simple bitmaps, we really need some sort of Lempel-Ziv algorithm going. And no, they're not that difficult to implement.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
TEA is insecure. XTEA fixes those insecurities, though some have been found in it (Note that this is not yet a cryptographic break). XXTEA fixes the vunerabilities in XTEA, though an attack has been found for low round version (Less than 8 rounds).
In any case, the TEA family is a lot smaller than Blowfish and AES, both in hardware and software.
Note that XXTEA only requires adds, subtracts and fixed shifts, which can all be implemented easily in hardware, and one multiplication and division, which can be eliminated if a fixed number of rounds are used.
In any case, I think encryption is a bit of a waste of time. . .
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E3 = Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
You have to understand that through all known history and through all known civilizations, COMMUNICATION was the privilege of the king, the high priest, and the government. No one was ever allowed to distribute anything except the official versions, by threat of capital punishment (or cutting your tounge in more civilized communities)
But even spreading the official news could be dangerious: "I know you are reading the gospels to the people, but I do not like the way you do it!"
All regulations regarding mails, telephone, telegraphy, radio, tv, internet are structured according to the scheme that the governments grant exceptions to their most generic asset: To hold the truth and distribute it ad libitum. This has always been monitored by strict censorship, the prerequisite for it being the strict ommission of all ciphers.
Very well known are the uses of "open ciphers" in literature.
Persons using cipher were outlaws, subversives, or - indeed - business men.
In some western countries the "age of enlightenment" started a slow change to this basic attitude; and the living at the "western frontier" was one of the efficient supporting forces. But it still took an immense struggle arround 1970 to make the shift - in some western countries!
The most common was a broomstick and a strip of cloth or paper.
Wrap the strip around thee stick so that it makes a nice, tight spiral with no gaps or overlaps.
Then write your message along the stick(you may rotate the characters so that they are aligned along the strip if you want). When you've written the message(you may write more than one line if you want to), unroll the strip, then write random characters in all the empty areas.
To decode, just wrap the strip around a stick with the same diameter as the one used when coding it.
It's even possible that they might have two messages on th same strip by using different size sticks.
(The romans were good at delegating control, but they didn't always trust the ones they put in charge. What better way of giving orders to a trusted agent than to code it into 'official' orders to the flunky? This is a brainfart of my own, and there's no historical evidence that the Romans used this technique )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
It however might have been also used as an implicite authorization! Simple as it is to decipher, it is not so easy to guess what SKYTALE will be used for the receiver without much more espionage.
And note that Gadgetman is talking about the Roman administration, not about the "Romans"
Post Edited (deSilva) : 3/9/2008 10:59:13 AM GMT
I would like to encrypt the file with a secure algorithm such as Blowfish etc. My knowledge of encryption is scant to say the least.
Is it necessary to decrypt the complete file before reading the blocks of characters or is there a way to decrypt the characters 'on the fly' as they are needed. I have played with a simple XOR key which has given adequate results but I'm just concerned about the level of security.
Does anyone know how I can reliably and securely achieve this?
Thanks
Paul
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"There are 10 types of people in the world. Those who understand binary and those who don't."
now if you are looking to encrypt data and put it onto an sd card. otp is the most secure and simplest encryption method available. it requires hand delivery of a large encryption key though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My new unsecure propmod both 1x1 and full size arriving soon.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
I understand what you are saying. Call me naive but what about these two 'possible' solutions:
1) what if the prop had two SD cards. One to contain the file to be read and the second to contain a key to unlock the file on the other card. Ok if the 'criminals' got access to both files they could crack that file but not any subsequent files.
2) If the key was held in a battery backed RAM (or SRAM/FRAM). How easy is it for the 'criminals' to read the contents of the Ram?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"There are 10 types of people in the world. Those who understand binary and those who don't."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My new unsecure propmod both 1x1 and full size arriving soon.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
the data is of reasonably low value on a file by file basis. I would just rather that they do not get one key that will unlock all files. I cant say what the data is at this moment. Sorry!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"There are 10 types of people in the world. Those who understand binary and those who don't."
if the card is ment to be a permenent ficture inside the machine then you are better off to try and build in tamper protection devices to erase the card or at least the key.
Some protection devices available to you:
1) remove physical access to code. This is the idea behind my secure propmod. I built it so that you can program it then secure the code. to access the code after that would require carefull destruction of the module. possible but difficult to do without breaking the eeprom
2) put key in non battery backed up ram. if power is lost even for a second key is gone. problem is lost also on inadvertent power loss.
3) actively look for tampering then delete data when found. photo detectors inside a sealed box, capacitive sensors between to metal boxs, there are many ways to do this and many ways to get around each. the trick is to not let anyone know what you are using and use more then 1 system.
4) Encrypt data. this only protects against people pooping the card out and reading. does little against someone with access to the hardware and knowledge.
4 works but not very well. 4 combined with 1 or 2 would work very well. 3 is the best but requires careful planing and the most expensive to implement and still best to combine with 1 & 4.
I mentioned my original propmod. http://www.propmodule.com/?x=products_propmod this has a built in uSD card reader. Implementing 1 & 4 with it would be easy as you can place the key in the eeprom and the data on the sd card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My new unsecure propmod both 1x1 and full size arriving soon.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
Keep up the good work and many thanks for your suggestions.
Paul
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"There are 10 types of people in the world. Those who understand binary and those who don't."
the original propmod is not doing to well. i have sold 4 and 2 of them to myself. Most people just aren't interested in code security. I have an order of 200pcb arriving on Tuesday and 35 props arriving Wednesday for my new unsecure modules and 1x1s. these look like they will probably do better. partially probably because they are so cheap.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My new unsecure propmod both 1x1 and full size arriving soon.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
Has there been any progress in putting this into assembly?
Thanks
Doug