Propcrytion
Destructinator
Posts: 34
To all those who are interested, Im beginning the process of figuring out a hardware based encryption system using the propeller architecture and the various cogs to supply multiple levels of encryption. If you are interested in this, I'll be able to fill things in as I go, but right now its just a theory. So if you want to know more later, leave a comment and if you have any sort of useful information about encryption systems please feel free to share. Any info would be appreciated
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Reach into a pocketful of dreams, now before they fall out of the seams" - Billy Talent, Pocketful of Dreams
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Reach into a pocketful of dreams, now before they fall out of the seams" - Billy Talent, Pocketful of Dreams
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I think the Propeller is a good platform to set up a fast AES-128 Processor, as the AES algorithm can be organized into pipelined parallel computations with 4x4 byte (4x32-bit) data. One needs one pipeline for the 'keyscheduling' and an other for the 'datapath'. In Prop two such pair of processes might run parallel (2x2 COGs). Two chunks of 16-byte data can be encrypted / decrypted in 10 rounds. In each round some data should be transferred between processes (once in one round). With a·quick GF(28) multiplication (only with seven small numbers including 1) and with some 256 byte table lookup Prop will shine. With a rather conservative estimate, 80-120 Kbyte of data may be encrypted / decrypted per second. The AES-258 needs more rounds and is accordingly slower somewhat. The question is, however, how to put that data in or get it out from the Prop?
Cheers,
Istvan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Intentionally Left Blank
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Yes, you can find FORTRAN, BASIC, Java, C, C++, C#, VB.NET and Python (or certainly more kind of) implementations. They came with many flavors of style: full algorithmic or full table lookup, or balanced between. All I have seen are sequential solutions, but the AES algorithm can be organized in two 'threads'. That would be more interesting and effective on a Propeller platform, than a 'simple' sequential code translation. Prop is able to run two such thread pairs (2x2 COGs) parallel. That is all that I tried to point out.
Anyway, to fuel the 'Fast, Faster, Fastest Code' (for the Propeller) series of threads, the dreaded, but in fact simple Galois Field (2^8) multiplication seems to be a good candidate. Extremely rapid performance, like with the byte multiplication (more than one million multiplications· per second), can be obtained.
Another thing. All high level language decommented source codes, are in the size 15-35Kbytes. For my taste, none of them are 'short recursive routines'. So, a 'simple' (public and really working) sequential translation for the Propeller would be a honorable task, either.
Cheers,
Istvan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Intentionally Left Blank
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Corwine
AES (Rijndael) is an advanced data encryption block cipher technique developed by Belgian cryptographers Joan Daemen and Vincent Rijmen. Its three versions (AES-128, AES-192, and AES-256) differ in their key sizes (128 bits, 192 bits and 256 bits) and in their number of rounds (10, 12, and 14, respectively). After a multi-year evaluation process, in 2001 the US Government chose AES as the new government standard (FIPS-197), replacing the older DES encryption standard. AES provides far greater security through much
larger key size and an improved encryption algorithm.
AES encrypts and decrypts 128-bit blocks of data with 3 standard key lengths:
1) 128-bit key length that corresponds to approx. 3.4 x 10^38 keys
2) 192-bit key length corresponding to approx···· 6.2 x 10^57 keys
3) 256-bit key length corresponding to approx.··· 1.1 x 10^77 keys
By comparison, DES has approx. 7.2 x 10^16 keys. To try and put this into perspective, if we assumed a super-computer could break the DES code in one second, it would take the same super computer 149 thousand billion years to decode an AES.
In June 2003 the U.S. Government (NSA) announced that AES is secure enough to protect classified information up to the TOP SECRET level, which is the highest security level and defined as information which would cause "exceptionally grave damage" to national security if disclosed to the public.
Up till now all attacks aren't effective against published full AES. The code is practically unbreakable (and God knows how many surplus rounds and what Sboxes are used by the agencies.)
So, you do not have to use random keys, at all. Just keep your key secret. When I say secret, I MEAN SECRET! If one does not know your key he is NOT ABLE TO BREAKE THE CODE. Be the key random or not. Of course, some common sense applies here, too. Do not rely on the encryption algorithm alone when protecting your data. Be sure you select a password or rather a "pass phrase" that is difficult to guess but still easy for you to remember. Use a mix of lower-case/uppercase letters, digits and special characters. It is obvious not to use the null key, or just the name of your girlfriend. Such a key· was called "cilly" by the british code breakers, and the radio operators hunted eagerly for those transmissions, where the german operator used repeatedly for the message key a simple girl name or initials to set the disks of the enigma. Such cillies were collected and tried first and helped a lot to decrypt the messages and brake the system, as a whole. One of those german gays used EVA always.
Note that in the encrypted byte stream any output byte can be a null, so it is not a simple string data.·
Use OTP if you want even more security.
Cheers,
Istvan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Intentionally Left Blank
Post Edited (cessnapilot) : 6/20/2010 9:28:17 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Reach into a pocketful of dreams, now before they fall out of the seams" - Billy Talent, Pocketful of Dreams
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Reach into a pocketful of dreams, now before they fall out of the seams" - Billy Talent, Pocketful of Dreams
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Intentionally Left Blank
So much nicer than dealing with all the problems
of distributing a secret key. But in the back of my
mind I keep wondering if some genius has come
up with a fast way to factor large primes.....? I
know it seems unlikely, but the Germans felt it was
unlikely anyone could crack that mechanical encryption
machine they used in world war two. It just seemed
so impossible to crack, we know how that went.
A fast block cipher might be something you could implement
well on a prop. There are some very fast and easy to code
stream ciphers around too. But with some of the simple
to code stream ciphers you need to be very careful or
you can weaken the strength of the encryption.
I believe that Chip Gracey wrote a random number generator
for the prop that he claims actually generates true randomness.
It's an amazing claim, not sure how to test it if actually can do this.
"Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin."
-- John von Neumann
Yea, I know all that. What I was asking is if the cipher needs sudo random data to actually perform the encryption, or whether the only input needed is the plaintext and my key.
EDIT: I see now - sudo random data is typically used for generating keys, not during the actual encrypting/decrypting. Makes sense, I'm not sure what I was thinking before.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Corwine
Post Edited (Nargule) : 6/21/2010 9:53:54 AM GMT
Depends. In order to protect yourself against "replay" attacks you should never send the same message twice.
Example: I send the message "Turn left" (M) to my robot as an encrypted message E.
My robot decrypts E and dutifully turns left.
It is possible some bad guy can listen to the transmission of E and record it. Then he might be able to transmit it again to my robot. My robot dutifully turns left again.
The attacker in this case need never decrypt the message in order to make use of it for his purposes.
So a sequence numbers or pseudo random number sequence in your message, checked by the receiver, can be used to defeat replay attacks. Or mixing up the data or key with a random sequence.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Reach into a pocketful of dreams, now before they fall out of the seams" - Billy Talent, Pocketful of Dreams
Depending on your application, XXTEA may be a great place to start. It is a relatively simple cipher that is secure under almost any circumstance. There is a known attack that requires the encryption of known plaintexts. This means that if someone wanted your key, and you encrypted information they gave you, using your key, they could look at the result and determine your key. This would still require up to 5.76*10^17 attempts, which is impossibly large for a microcontroller. (With the smallest blocks, at 64 bits, that is more than 4.6 Exabytes) If you are only encrypting your own information, then even that won't break the cipher.
— David Carrier
Parallax inc.
Right. My quote above is regarding a previous post of mine asking if sudo random data was needed for the AES-128 cipher to function. Of course, it isn't.
Good point about replay attacks, though. I've thought about this somewhat; I'm thinking the transmitter and the receiver would either need synchronized clocks (in which case we just pre-pend the output of a RTC to the message) or the receiver would need to maintain a table of commands it's previously processed (which is different every time due to us adding random data to the message).
Another thought is to implement something where a rolling code is used. I'm not sure how complicated that would be, but it seems like the most robust solution.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Corwine
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Reach into a pocketful of dreams, now before they fall out of the seams" - Billy Talent, Pocketful of Dreams
Post Edited (Destructinator) : 6/22/2010 2:41:30 AM GMT
I can break Your Proposed code that you haven't even writing yet. Heres how I would do it.
I would simply read the data stream from the SD card and compare it to the reactions on the I/O pins.(Running this over and over) After I ran out of different patterns, I would just compare what did what. My PC doesn't have a problem running billions and billions of 0s and 1s
I think the algorithm approach would work My PC a lot more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Truth is out there············___$WMc%___···························· BoogerWoods, FL. USA
want speed?·want·to use the Propeller?·want to stay with BASIC___www.propbasic.com___
You can feel stupid by asking a stupid question or You can be really·stupid by not asking at all.
·
And dont use a crc even a encrypted crc is straightforward to correct even through the encryption.
I can see what you are saying. But how would you get access to the SD card and I/O pins? This device is intended for say, network security, so its not going to be lying out in the open. Hardware based cryptographics is intended to be more difficult in that there is no software that can be hacked or cracked.This system is designed to have maximum effect with a minimal footprint, say about the size of a credit card.Your approach would indeed work, If you had access to the device, but anyone who is serious enough to buy a hardware based system, is not just going to leave it lying around to be hacked.
If anyone else knows of anyway that this concept could be easily broken, please let me know. It helps me to strengthen the concept.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Reach into a pocketful of dreams, now before they fall out of the seams" - Billy Talent, Pocketful of Dreams
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Reach into a pocketful of dreams, now before they fall out of the seams" - Billy Talent, Pocketful of Dreams
Post Edited (Destructinator) : 6/22/2010 1:10:55 PM GMT
Sorry for not paying attention, I see now that you want to make a Prop_hardware_key. This would be removed when one is done with the Application. So no Prop_hardware_key to hack. (sorry, I was thinking of a setup similar to a card in a cable/satellite TV set-top box, were the card was pretty vulnerable to a hacker.)
With a hardware_key, you don't need a whole lot of encryption. Take a look at how an ignition key works on a late model vehicle, First a mechanical binary code to release the tumblers to get to the "ON" position with the ignition switch, Then you need the rite RFID tag code(thats in the key) for the CPU to enable the fuel injectors.
If you implemented a number of trys and a time frame for your key to activate the Application, This would be very difficult to hack.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Truth is out there············___$WMc%___···························· BoogerWoods, FL. USA
want speed?·want·to use the Propeller?·want to stay with BASIC___www.propbasic.com___
You can feel stupid by asking a stupid question or You can be really·stupid by not asking at all.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Reach into a pocketful of dreams, now before they fall out of the seams" - Billy Talent, Pocketful of Dreams
Don't forget the·security of the·code itself - any encryption system is only as good as its weakest link, and having a leak on the·unencrypted-side (or unverified code on the sender/receiver) would let attackers peak into your plain-text before it's even encrypted...· You might want to try something the FPGA guys are doing now for anti-piracy, use a secure EEPROM and do a·hash of the·run-time code, send the·hash to the EEPROM for verification to ensure the platform is not tamplered with then expand your encryption/decryption engine from the EEPROM.
Also, remember - if you are doing a short lifecycle data burst (data that is immediatey reacted to, like in an RC car/robot), you only need a secure channel for key exchange, and you can use a simple XOR with the·exchanged key to mask the data+checksum like a one-time-pad (very fast) - you'd have to tweak the data and the checksum CORRECTLY, for the packet to be hacked, and the less you use the secure key exchange channel, the harder it will be for an attacker to hijack the keystream.
Post Edited (GreyBox Tim) : 6/24/2010 3:59:41 AM GMT
I should correct that statement strictly they dont provide replay but they require a nonce which is commonly an incrementing number which can be used as the replay counter·providing both with a single number.
Post Edited (Timmoore) : 6/24/2010 4:32:37 AM GMT
Assuming the RC transmit/receive pair:
nonce && Message = PlainText
PlainText && KeyedHash(PlainText) = SenderData
Compress(SenderData) = Payload
Encrypt(HW-RNG && Payload) = CipherText
This requires on the receiving end that the following happen:
Decrypt(CipherText) = HW-RNG, Payload· <-- Receiver must strip the correct number of bits to have the valid Payload
Decompress(Payload) = SenderData
Split(SenderData) = PlainText, KeyedHash <-- Receiver must split off the correct number of bits to sepearate the Hash from the data
PlainText·== KeyedHash(PlainText) <-- if true, plaintext is valid; if false, discard data and NACK packet·(or reset link)
Split(PlainText) = nonce, Message·<-- Receiver must split off the correct number of bits to separate the nonce from the message
nonce > Lastnonce <-- if true, data is valid - set Lastnonce to nonce and ACK packet (only at this step); if false, discard data and NACK packet (or rest link)
Act on data if valid
For nonce you can do many different methods, a rolling counter, UNIX time (which would require more stringent syncronization of your system clocks), etc...
Other recommendations, encryption keys can and should be changed regularly - the more often they are changed, the harder it is to crack the next transmission.· Keys for hashing, should be between two parties only - this is an added addressing measure (I think NIST suggested a public key method for checking keyed hash, but I don't recall).· Only the target that the message was intended for will be able to correctly verify the hash, all others will fail that check - this is one suggested solution to the Byzantene Generals Problem when data is forwarded·(but this is subject to correct implementation on the receive-side, the receiver could just decide to use the data anyway, and then you can kiss your security goodbye...).
Initial key exchange should probably use Public-Key methods - Skype did this, the client has the public key of the server, it encrypts a random chunk of data and passes the public key (uniquely generated at install or at the start of every session) of the client to the server.· The server generates a chunk of it's own random data encrypts with the client's public key·and sends it back to the client.· Both the client and server hash the concatenated random data using an accepted cryptographic hash and the client replies to the server an encrypted ACK·using the hash result as the key.· If the server does not see the·ACK within the timeout, the link is reset.· If the client replies with a NACK, the link is reset.
This way neither party can have full control of the key construction, so even if the same random data is sent from the client the final key will be different (and the server can be programmed to reject a random seed it suspects is compromised by resetting the link, disallowing a client's public key, disabling the account, etc...).· Once the link is established, a key exchange can be done over the secure link without the extra steps.
-T
Post Edited (GreyBox Tim) : 6/25/2010 7:08:18 AM GMT
PS, Would anyone be intersted if I made this up in EagleCAD as a diagram? Also I can post a parts list from sparkfun as to all the extra bells and whistles.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Reach into a pocketful of dreams, now before they fall out of the seams" - Billy Talent, Pocketful of Dreams
If you're looking to learn, take a look at this site: http://www.itl.nist.gov/fipspubs/by-num.htm
AES = Pub 197
Secure Hashing (SHA1 - SHA512) = Pub 180-3
Keyed-(H)ash (M)essage (A)uthentication (C)ode (aka HMAC) = Pub 198-1
Digital Signal Standard = Pub 186-3· <-- this is the one I recalled where they use a verion of public key cryptography for signature verification.
And by all means, if you have an Eagle drawing put it up - there may be usefull comments, and it might spark an idea with someone who is even more "green" than you at this.· Also, before I sound discouraging - every security book I've ever read, and all the experts I've ever talked to all repeat the same basic rules:
-T
Post Edited (GreyBox Tim) : 6/25/2010 7:51:52 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Reach into a pocketful of dreams, now before they fall out of the seams" - Billy Talent, Pocketful of Dreams