MD5 Object Problem / SHA-1 Replacement

Bobb Fwed · 2011-08-22 16:43

I'm having problems with the MD5 object.
First of all, I'm not totally sure I am using it correctly (as there are no examples, and there are nondescript parameter names, like "h").
But I think I am using it correctly, but the results are not as expected.

I have this code:

VAR

  byte str[100]
  byte rt[32]   ' double intended size, just in case...

PUB Main | tmp, i

  tmp := string("1234")
  bytemove(@str, @tmp, strsize(tmp))

  MD5.hash(@str,strsize(@str),@rt)

  waitcnt(clkfreq + cnt)
  REPEAT i FROM 0 TO strsize(@rt) - 1
    DEBUG.hex(rt[i], 2)
  DEBUG.tx($D)

it outputs 16 bytes as expected. But the result is based on the local address of certain things.
It outputs
4B43B0AEE35624CD95B910189B3DC231
When I am expecting
81dc9bdb52d04dc20036dbd8313ed055

BUT if I add a " / 2" to the clkfreq in the waitcnt, it changes the result to
7B774EFFE4A349C6DD82AD4F4F21D34C

In the MD5 object itself, I presume the parameter "h" is the hash, and I am also guessing it is the address to store the hash (as that part seems to be working correctly -- even if the hash itself is not).

What am I, or the object, doing wrong?

kuroneko · 2011-08-22 16:51

Bobb Fwed wrote: »

PUB Main | tmp, i

  tmp := string("1234")
  bytemove(@str, [COLOR="red"]@[/COLOR]tmp, strsize(tmp))

That looks wrong.

Bobb Fwed · 2011-08-22 16:53

nope, tmp is already an address.

kuroneko · 2011-08-22 16:56

Yes, exactly. So no point passing a reference to an address (your original code does). And the display loop should only go from 0 to 15 (don't use strsize).

Bobb Fwed · 2011-08-22 17:30

kuroneko wrote: »

Yes, exactly. So no point dereferencing it again (your original code does). And the display loop should only go from 0 to 15 (don't use strsize).

Right, of course.

Mark_T · 2011-08-23 04:16

BTW I hope people realize that MD5 is "considered cryptographically broken and unsuitable for further use". (And has been for many years)

idbruce · 2011-08-23 04:38

Bobb

Ahhhh Cryptography

A subject near and dear to my heart. Not that it directly applies to the Propeller or that it will particularly help you in this case Bobb, but it does apply to cryptography. Here is a link to some cryptographic functions that I wrote over eight years ago. That brings back some memories. Who knows, maybe I could incorporate the functions into the serial terminal that I am working on now, providing that you create a nice object on your side Bobb. Good luck with it.

http://www.codeguru.com/cpp/misc/misc/cryptoapi/comments.php/c3899/?thread=47896

Bruce

idbruce · 2011-08-23 07:16

Bobb

I started digging around in some of my old C++ files and came up with some fairly serious cryptographic functions that I wrote after I had gained some experience with the Crypto API. As I previously mentioned in the other post, I would be willing to add these functions to the serial terminal I am working on, and so I have been thinking about it. So let me ask you, what is encryption used for on a uC? Because as I see it, this serial terminal should be able to read and write files, and I would imagine that if the serial terminal had unicode support (which I believe it does already), the prop could send encrypted data to the terminal and be decrypted.

Bruce

Bobb Fwed · 2011-08-23 08:43

Mark_T wrote: »

BTW I hope people realize that MD5 is "considered cryptographically broken and unsuitable for further use". (And has been for many years)

Yes, I understand this, but MD5 is still relatively secure if the input is salted and size-limited.
More so, I was just being lazy and hoping for an already existing object for a well-established hash. But it looks as though I will have to create my own, I'll probably try my hand at creating a SHA-1 function.

Bobb Fwed · 2011-08-23 08:50

idbruce wrote: »

Bobb

Ahhhh Cryptography

A subject near and dear to my heart. Not that it directly applies to the Propeller or that it will particularly help you in this case Bobb, but it does apply to cryptography. Here is a link to some cryptographic functions that I wrote over eight years ago. That brings back some memories. Who knows, maybe I could incorporate the functions into the serial terminal that I am working on now, providing that you create a nice object on your side Bobb. Good luck with it.

http://www.codeguru.com/cpp/misc/misc/cryptoapi/comments.php/c3899/?thread=47896

Bruce

That would be some good functionality to have. I will consider doing that work. Right now, I don't have any need for 2-way cryptography, but I have in the past, and have settled for less.

Bobb Fwed · 2011-08-23 13:58

Well, I'm pretty sure I have the algorithm put together in SPIN, but after my first test, I notice something immediately wrong (that I should have picked up on earlier)...the algorithm requires unsigned variables. Bah!

I've put this much work into, guess I'll be converting it over to PASM.

Also the whole little endian, big endian thing is wiggin' me out, and I'll probably do it wrong.

idbruce · 2011-08-23 14:46

Bobb

Since you are wiggin' out, I am curious which one got your scalp. Was it the big indian or the little indian, or did both get a little hair from you?

Relax, take a deep breath, then go back refreshed and kick some code in their face.

Bruce

Bobb Fwed · 2011-08-23 15:06

The problem is, all the longs in the algorithm are expected to be big endian, and the Prop handles everything in little endian. I think i did it right with the byte moves and such. But I don't even think the initializing constants are correct because of it. And finding a well-broke-down explanation of the bit structures as the algorithm runs is dificult. So all I get is a result, and it could be a little/big-endian conflict, or I missed an XOR somewhere, or a dozen other things. You know how programming goes. The most aggravating programming problems are the small ones, misplacing decimal points, leaving out a semi-colons, and the like.

But now that I am porting it to PASM, and there ain't none of that block moving there (I'll being writing it myself). I'll figure it out in the end, I (almost) always do.

idbruce · 2011-08-23 15:19

Bobb

I can relate to your problem. When all you get is the result, it does make it more complicated.

I'll figure it out in the end, I (almost) always do.

Good luck with it Bobb.

Bruce

Bobb Fwed · 2011-08-23 17:03

OK, after completing the PASM version, still no luck on results. But the more I think about it, the more I think it's not possible without a lot of slow programming.
The problem comes with bitwise operations like rotates. A little-endian rotate left 1 bit and a big-endian rotate left 1 bit will have completely different results (if there is any rollover between bytes).

So, I don't feel willing to put all the time in to convert longs back and forth between the endians. Rather, I think I'll release it as Prop-SHA or SHA-Prop or something, a proprietary SHA.

Attached is my SPIN and PASM attempts at SHA-1. SPIN isn't commented much, but it's copied almost directly from the Wikipedia website, and the PASM is commented with SPIN equivalencies.
Currently (as it is in Alpha) it only works with strings that are less than 32 bytes long.

Maybe someone will see a mistake, or know an easy way to solve the problem.

Mark_T · 2011-08-25 08:32

SHA-2 family are the recommended hash functions these days, perhaps SHA-256 is the one to aim for (although SHA-2 is going to be replaced by SHA-3 at some point).

Of course more modern hash functions typically have much larger output sizes than MD5 which is an issue on a space-limited microcontroller.

Perhaps RIPEMD-128 might be a good compromise? The table at wikipedia has a summary of hash functions and crypto-attacks upon them: http://en.wikipedia.org/wiki/Cryptographic_hash_function

Bobb Fwed · 2011-08-25 09:58

But as stated on that page, SHA-1 only has problems with collisions, which isn't nearly so much of a problem.
I just read an article stating a university in German has figured out a way to force collisions some 2000 times faster than brute force, which isn't so bad when there is still 2^51 number of possibilities to go through (something like 6 months of community hacking to make that useful -- but a higher security flaw than the expected 1000 years). For online certificates it poses a potential risk, but for the extremely memory-limited platform that is the Propeller, a common hash seems more useful than a more secure hash.

SHA-2 takes up a lot of memory, and come to find out, kuroneko had a solution that he PM'ed to me.

Mark_T · 2012-02-03 14:48

As its relevant to this thread, just mentioning that I've just made a SHA-256 object available in the ObEx, mainly in PASM, seems to work nicely, speed of about 230kB/s or so. Called "SHA-256", naturally.

MD5 Object Problem / SHA-1 Replacement

Comments