macOS md5 encryption in OpenCL

[Cbswe]

Hi!

I have a quick question.

How challenging would it be to write a md5 encrypter in OpenCL?

Me and my friend is thinking of writing our bachelor essay about such an implementation and the possible speed advantage.

Any comment and/or view is appreciated!

 

[ulbador]

It all depends on your programming skills. MD5 is a very well documented algorithm and porting it shouldn't be an issue at all, given there are some VERY low level examples of how to implement it.

 

[Cromulent]

MD5 is not encryption.

 

[Cbswe]

It all depends on your programming skills. MD5 is a very well documented algorithm and porting it shouldn't be an issue at all, given there are some VERY low level examples of how to implement it.

That was what we thought as well. The only part that's worrying is that OpenCL is not the easiest language to write in and we have no previous experience in it.

However, we got 2.5 years of academic studies in computer science and have learned a lot of languages before as well.

MD5 is not encryption.

Right you are. Sorry It's a cryptographic hash function.

 

[gnasher729]

Hi!

I have a quick question.

How challenging would it be to write a md5 encrypter in OpenCL?

Me and my friend is thinking of writing our bachelor essay about such an implementation and the possible speed advantage.

Any comment and/or view is appreciated!

Look at the MD5 algorithm. Can you find any operations that you can do in parallel?

 

[balamw]

Is MD5 CPU or I/O bound?

I would have assumed the latter since it has been around since CPUs were not much more than fancy abacuses And of course it's goal is to take lots of data in and spit out something much smaller.

Look at the MD5 algorithm. Can you find any operations that you can do in parallel?

And that too of course.

B

 

[Cbswe]

Look at the MD5 algorithm. Can you find any operations that you can do in parallel?

Is MD5 CPU or I/O bound?

I would have assumed the latter since it has been around since CPUs were not much more than fancy abacuses And of course it's goal is to take lots of data in and spit out something much smaller.


And that too of course.

B

I'm sorry, I must have misunderstood the algorithm then. I got the understanding that it worked on 128 bits at a time.

 

[balamw]

I'm sorry, I must have misunderstood the algorithm then. I got the understanding that it worked on 128 bits at a time.

512 bits according to Wikipedia, but the accumulated hash from the previous 512 bit sections is used in calculating the hash for the current section, so you can't easily parallelize it.

(If they were completely separable, how would you tell the difference between a 1024 bit stream composed of 512 bit sections A then B vs. B then A?)

http://en.wikipedia.org/wiki/MD5

I may certainly not be understanding it right either, so feel free to correct me if I'm wrong.

B

 

[gnasher729]

512 bits according to Wikipedia, but the accumulated hash from the previous 512 bit sections is used in calculating the hash for the current section, so you can't easily parallelize it.

(If they were completely separable, how would you tell the difference between a 1024 bit stream composed of 512 bit sections A then B vs. B then A?)

http://en.wikipedia.org/wiki/MD5

I may certainly not be understanding it right either, so feel free to correct me if I'm wrong.

B

MD5 adds a bit of padding and stores the data size at the end of the stream, so that you have a multiple of 512 bits. These are split into sixteen 32 bit units, and tons of dependent operations performed on these 32 bits, mixing them with the other 32 bits all the time and doing different operations on each of the 32 bit units.

You have no chance of using OpenCL in any meaningful way, no chance of using SSE, no chance even of using 64 bit capabilities of a processor except for the fact that it has more registers, but then you lose out because the algorithm requires 32 bit shift operations. Every step is dependent on each previous step.

 

[Cbswe]

512 bits according to Wikipedia, but the accumulated hash from the previous 512 bit sections is used in calculating the hash for the current section, so you can't easily parallelize it.

(If they were completely separable, how would you tell the difference between a 1024 bit stream composed of 512 bit sections A then B vs. B then A?)

http://en.wikipedia.org/wiki/MD5

I may certainly not be understanding it right either, so feel free to correct me if I'm wrong.

B

MD5 adds a bit of padding and stores the data size at the end of the stream, so that you have a multiple of 512 bits. These are split into sixteen 32 bit units, and tons of dependent operations performed on these 32 bits, mixing them with the other 32 bits all the time and doing different operations on each of the 32 bit units.

You have no chance of using OpenCL in any meaningful way, no chance of using SSE, no chance even of using 64 bit capabilities of a processor except for the fact that it has more registers, but then you lose out because the algorithm requires 32 bit shift operations. Every step is dependent on each previous step.

Thanks! You saved me and my friend from a lot of trouble!

We decided to find another problem that's certain to be parallely calculable.

I might have realized the absurdity of the proposal if I wasn't so sleep deprecated today and the deadline for the proposal is tonight

Macrumor forum is a lifesaver.
Thanks guys!