Need help to understand encryption objects
Don M
Posts: 1,652
I want to play around with some encryption. I was going to have 2 props talking back and forth to one another. I see there are a few encryption objects but I don't understand how to use them.
For example I want to encrypt this serial string: $00 $C8 $00 $03. I would like to setup 2 quickstart boards to talk to each other for testing. One would have the original un-encrypted string and a key (?) to encrypt it. The other would have the key and un-encrypt it.
How do I go about this? I am interested in AES128 bit. The demo for it does some fancy stuff but I don't understand his demo. I was hoping for a simpler type of demo where I can just plug in a key, plug in the clear text and viola' I get encrypted string out.
Has anyone some good experience or suggestions with this?
For example I want to encrypt this serial string: $00 $C8 $00 $03. I would like to setup 2 quickstart boards to talk to each other for testing. One would have the original un-encrypted string and a key (?) to encrypt it. The other would have the key and un-encrypt it.
How do I go about this? I am interested in AES128 bit. The demo for it does some fancy stuff but I don't understand his demo. I was hoping for a simpler type of demo where I can just plug in a key, plug in the clear text and viola' I get encrypted string out.
Has anyone some good experience or suggestions with this?
Comments
Have you tried Mark's SHA256? Give a paraphrase, get the key, hash it with your msg & then send over to the other Prop. The other Prop will need the same key.
I know its been almost a year with this but I never got around to fully understanding this and now its time to look at it again for a project.
I downloaded Mark's SHA-256 Demo and it runs on my Quickstart. Sorry if I seem ignorant but I'm trying to get my head around how this can be done:
Quickstart1 will have its own Private key.
Quickstart2 wants to send an encrypted message to Quickstart1.
Quickstart2 will use a Public key to encode the message to Quickstart1
So how does this scenario work with something like Mark's object?
Where / how are these keys made? Do I just pick a private key like this: ba7816bf8f01cfea ?
Can someone give me a working scenario or roadmap as to how this all works?
Thanks.
Don
You take the 3 charcaters- "a" "b" "c" and run them through the hash and you get: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
But what do you have to do to take this long hash string and get back to "a" "b" "c"?
build an encryption function from a hash function, but you _really_ do need to know what you are doing.
AES is a symmetric encryption algorithm, there are no public keys. For that you need a public/private
algorithm (asymmetric algorithm) such as RSA, and this is normally used just to exchange a symmetric
session key. For that you need a cryptographically strong random number generator that's secure
against replay (really hard to achieve on a microcontroller).
Firstly do you need encryption? Or do you need authentication? For the latter a MAC is the normal
solution (Message Authentication Code) - this is like a keyed hash function.
Suggested first reading is "Cryptography Engineering" by Schneier et al.
And don't forget those replay attacks...
To expand on what Mark said, here are the algorithms and what you use them for:
This is used as a one-way method to produce a (hopefully) guaranteed unique string from a given input. The theory is that for every given input, there is exactly one unique output. When an algorithm generates multiple exact outputs for different inputs, this is called a hash collision and essentially means the algorithm has been defeated. The MD5 algorithm was used for a long time, until it was mathematically proven to have collisions, then real collisions were found, so it isn't sound anymore. The SHA1 algorithm (SHA-160) is now considered to be broken as well, because the number of rounds is insufficient to produce a secure hash and it has been defeated theoretically. The algorithm generally considered the least complex and still robust is SHA-256. This is what is implemented in the bootloader authentication of the Propeller 2 ROM.
A hash is used to generate a checksum for an input string, but the checksum is unique and no other combination will yield the same checksum, so you are assured that if a given stream of bytes calculates to a given checksum in two places, it's authentic. This is the *theory* of cryptographic hashes, however reality is that it only takes a given amount of computing power or a novel new attack to discredit a hash or cipher.
This is short for Message Authentication Code, it is a method by which you can take a secret key and a message and produce a hash which is perturbed in a specific way to represent the amalgam of the secret key and the message hash. The HMAC algorithm is a common MAC implementation and is used in the Propeller 2 boot ROM for authentication. It works by hashing the message combined with a pad derived from the key, then hashing that hash with another pad derived from the secret key. By doing two round of hashing, it is supposed to perturb the hash in such as way as to completely obscure the key.
On the receiving end, you have a shared secret key that you use to perform the same calculations, and should arrive at the same answer as the hash sent with the message. This assures the message is genuine and the message isn't corrupted.
An asymmetric cipher is used for exchanging information one way in a secure manner, without having an foreknowledge of the key. In essence, the sender asks the recipient for their "public" key, this is a prime number which corresponds to another prime number which they hold secret (the private key). The algorithm encrypts the message with the public prime number and the recipient decrypts the message with the private prime number. In this way an initiator can open a communications channel with a recipient and send them a symmetric key, so the recipient does not need to know the key before hand and the recipient does not need to divulge any secret knowledge to the sender.
This is how SSL encryption is done, the client connects to the server and exchanges a symmetric key, which is used to secure the session beyond the key exchange.
Another interesting use of this public/private key pair is digital signatures. With the private key you can sign a message and use the public key to verify the message. In practice the way this is done is the public key is stored either locally or in a key lookup server. A message that needs authentication then uses the public key to authenticate the message sent by the owner of the key. Only someone possessing the private key can produce a signature that matches for the corresponding public key.
Commonly used ciphers of this class are RSA for encryption and DSA for signatures.
These ciphers are the workhorses of encryption, doing the heavy lifting. They encrypt and decrypt data in blocks. The key is used to encrypt the data, then the encrypted data is run through a decryption routine, using the same key, to produce the cleartext. A common example is AES-128 or DES. DES has been deprecated due to it's low complexity and the viability of compromising it with modern FPGA hardware. Triple DES is still in use though, comprised of 3 rounds of DES.
One of the limitations you are going to face is that symmetric block ciphers work in chunks, and in the case of AES-128, the block is 16 bytes long, your example only had 4 bytes per message, DES uses an 8 byte block. There are a variety of symmetric ciphers called stream ciphers that work in streams of data, which provide continuous encryption, these are described here: http://en.wikipedia.org/wiki/Stream_cipher
Hopefully this has cleared up some confusion and I haven't given any wrong information.
re: Re: Need help to understand encryption objects
Very good explanation.
Thanks for that great summary of crypto technology.
One little point though:
Re Hash: Yes but, given that hashes are short sequences of bits derived from much large lumps of data there can never be a one to one mapping between different input to different output. There will always be many possible inputs that will have the same hash. No matter what algorithm is used.
Clearly in the extreme a 1 bit has only has two possible values, half your inputs map to 0 and half your inputs map to 1.
A two bit has is not much better, a quarter of your input all map to the same value, a quarter map to another...
You see where this goes, even with a 256 bit or more hash there are far more possible inputs than outputs.
In that way all hash algorithms are defeated before you start !
It's not so bad. The idea is that with a 256 bit or more hash the numbers we are dealing with are unimaginably huge. The practical reality is that here is a vanishingly low probability of finding any file that maps to the same hash as some other file.
The "defeated" part comes in when someone finds a way of easily finding that second file that maps to your hash. Or perhaps working out how to modify a wrong file so that it maps to your hash making you think it is legitimate.
Mark_T, The Propeller has a means to generate real random numbers from hardware. See "Real Random" object in obex.
I have often wondered what tests of Real Random's output would convince cryptographers that it is cryptographically secure?
Hence my ending note on hashes:
This is the *theory* of cryptographic hashes, however reality is that it only takes a given amount of computing power or a novel new attack to discredit a hash or cipher.
That basically says that hashes are not collision free, it's just that we don't have the means to find 2 messages that produce the same hash in a reasonable amount of time and effort.
After reading a bit from this thread and others the above is what I'm interested in trying to understand how to do.
I have this message:
79e47668d626755f6962e6dd861ce0b116c5bef912345678903,c
And have encrypted it with this Public Key:
AAAAB3NzaC1yc2EAAAADAQABAAABAQDHWh5r7R4kfW+EPyQPq3r0pG10sOFy2KGu7oTeXN/J0Mp3J82PxR3v+B3GGivod25rb692A2/iWaVyyrFPbMtY46xx/a5Jgw/25CRYHvDWioiKon6y8pFXyvCXaPHCpBxw9x3+SSNSlmqX6H/xhKPhwgSiea1SUJ9EatdRpv6kljUZg34gqMmxTbBevaPta44VisRgN03keR5S8VceTdAvkbUg+8mvcpu81GF4PLcWBcZvvlSz7PT+QGkV8r7LRvIE5KRw8p0pXAYK8pqBVo4z85BT+tQHgYIuTDopRQkSwtFkx/VqXpoN3dyYB2ptlqRPf9MbVOjfS2NEJZqoPZMN
To get this result:
4D9EF0C37E53ADA1D3D87052B63B8CDEEE409EBA867D692372416CA070D41BF1EEC4816EFEE83BCC477B4411B02C1A696113A990098DA6BD5A53CE879291FBA84D0C4225DF6D0FCD828607A4BB979752D01EBDB1FCA3516F49558317187CF218A68E209FB13F9503DE8A0B22DBCC5C94446BF36216EDFEC0DD323EFBF3D7B7FC0F24EFDC9A145574F24ED64FF555D3B2BEA465C2F0A953B6DDE23177AF71F6E1B27B477B6DCB58ED7AB4F289684458762D508CF5C38F5D8AA516E468ED7BC0070743900BB0C585ADAB9287441DCB3428D62CD7360E338A4052365F38BA2B524F5415680F16EDCAFC72E0EAED3E0506380D1353E2E952DFDE03FA89216917730C
This encrypted message is then received by the Prop. The Prop has this Private Key:
imxxmsNYb1haCfUfEDXyNCYCzriuTVnXostpFqvJ1nSpI1fkGsdtxgjnS52fiHKM
BT8asFH3eK4ew36gQzN+9ScQtjuK7+bEqBRrpqS/Q+5iV2Ic96YgGqyuje7uXoAE
t/uFosO7jE0cMw6yLNQ8prQUNdPgenQIJTxbMRKpr3Dd/o9PycHWhGe3wdyQEWE6
1AIU5kJTQYRei5dYWsqT33DDuKAW01Wjt6HZpo2CmgndtpEup1e3OX1TUgq4sunn
Rc7WfNbFBqx9XHF26UHUz9lqwAq39xyEF/kjGo1lFlTCG5uOyte7KbWqxSiVSEWG
0egTIZ4XVdxO+jmNVrM/bhKA4EBXcErfd8JGKaOXGJJDotrHkaj+z1WyTvfZs5rN
zyGVrxur/O276Cdw41a+YQK0hFFPmAgGrsDzNBdYNfrN5gdJpxDAWMzcpBAaoRtU
Mo35jEzNnc7F/uO5KvOYh/ATlB/nBADW0F+MHnWntdmTOvQdI3NDiUfD5eL8BZpz
cV8ayHgaY4DiWor7UscpooiBDGDjvcjgugycLazZxuvz8olXWPWRQfAcEw4Nhj1c
5Ci5e5LhtwwDf5/+GJbSWPHxeOeXEiEQsz4UNbzyqRZPxTBXt038mLGkIzHV7aS7
zkOpyK1sTVGcAz/n8t+dC6kErj52PSh2PNRG6uscBzTDTpvhmK13AdC9N+kCMPEv
RqMJuxz4TLVGSqZ5LLWGqef1QVJjhS0/3uSCNdKfTj61iCdtIAqJ0V29OeSjpvA4
facsNFwZmzWhnTZUwKv9X7qjhVKm2A7ScT7wZuRTTwVl4xWBdAF++Zk2d/bmp+0h
4wrVuxbmdhUfg7c+C8dE4Bj1DLx80fzvn/s3ouhDCnpGeDyOUIYg7pTGF7FRU5Uh
FLzGovZPqUarrvvUcK3Fz3pkjOJMlZhxrUI2zcRyantV9c6XOhpNWr7XplJd9emu
NbV0ptJ9ySBVJG2xXWwY3rMWi6PxmDfoxh5q3uFQSwcrE3Wo9K3u0RwfI1YQBVxv
lwdba0x3p7UOStVQvcXcj4avWRkdSpMu6d1976O22hXCGzQMTGKSK70bp4jNZkqH
+wqIXaX/goZuizjr7V6vPe0Lkry+BYeKz0kwJoNonRyhls4Zx50gZEKJAjVPe7r4
rzSbiyidXptw+qdS6o+8A26oQJMaqumB70u5tQBNhv1vLK+b6ALZyCaU/Wgf1xVh
aLOTsON+BWB0CfOB1ZilSBMKQdBJw5ePL5Vxe8rdOQOZiZAt75kgeUiiZKMbcY9I
0gDoMSAG49s7EH+/oUjXG+oQ+/xPgFH21wNmc1bhiHezXKIUMa047MKUZROD9gLK
k7HHOvuV/WGLlsrUY0IaKTuh0/cNmPHzrKLbhsKkq/WZ6/5b5royvYdraleK5eYX
hgSpVPkI8VXfXCPjx/ID9s6/wxZs5xRMGSyc0qPn4pWC+WzgGFjxfPHL0lknGJ6Q
PqDzccUZch7B3VT61+31kqQYS1rp9wLW64wL0yoxumzF5yjO4UrsPEQCoUYVyvX2
8y8qqSFKpF8Lg3pjRE4bqCjbxGcg+LBTA5nx1hRN/Yj9oHmLaquIH/kvyNgAag6X
So how / where do I find the algorithm to decrypt the message using this Private key?
Is this possible with the Prop?
Thanks.
Don
http://en.wikipedia.org/wiki/RSA_(algorithm)
Decryption
C is Ciphertext
D is Private Key
N is Public Key ?
M is the result after decryption
I have no idea how to do this type of equation on a Prop.
When working at the embedded level, you have to roll your own sometimes.
My recommendation is to look around for some existing libraries that implement encryption (OpenSSL is on popular variant) and pick pieces of code out of the library to implement what you need.
When I wrote SHA-256 in assembly language, I got the C source by searching google. I found at least 2 implementations, one was more standalone and easier to read. Between the practical code, the algorithm description, FIPS doc, I was able to get a working piece of code. I spent about 24 hours writing and validating it.
For optimization I looked at some of the other code out there and was able to rearrange some instructions to reduce size/increase speed, even if just a few instructions or clock cycles.
You have the advantage of working in C, so you can find existing code and adapt it.
One thing to consider is that you only need the part of the algorithm you are going to use. That means if you only plan to decrypt, you only need that part, so it lessens the need to port all of the code.
There are also two parts which will need to be coded: the algorithm and the "wrapper". The algorithm is all of the code which does the actual work - all of the math bits. The wapper is the code which uses that algorithm. In this case you have some plaintext, keys and ciphertext - all expressed in some format. So the wrapper code needs to understand that format in order to put the inputs & outputs in a format the algorithm can work with.