Implementing Cryptography with OpenCL

Hey all! Welcome to CryptoCL.

As we’re nearing the final days of working on the Hands-On OpenCL tutorial, I am wrapping up Exercise #09. On Thursday, I was able to resolve the issues I was facing with getWorkGroupSize and getInfo. Both problems were resolved by declaring and assigning a cl::Device, instead of using the DEVICE defined variable.

The program began to seg fault after these issues were resolved and I was able to program the code. The cause of the seg faults appeared to be some issues of some un=assigned values, values that were not assigned correct values, and filling a vector that would hold the partial sums of the program was being assigned the incorrect amount of items. After fixing these assignments and removing the for loop to fill the vector, the program runs to completion, but does not return the right value.

I met with Dr. Marmorstein to discuss the solution and, after digging through the code, we discovered that a value “nwork_groups” was not being initialized before the partial sum vector was being created, so the vector was being initialized as a vector of a null size. Switching around the order of code allows for the program to run and print the correct value of pi.

Lastly, during this same meeting, my next plan of action was made clear — I am to study a project found on GitHub called clblake. It is an implementation of an older version of BLAKE using OpenCL. Having a look at how GitHub user wfr handled implementing the cryptographic algorithm can offer insight on how we can implement our own implementation.

Until next time!

Kyle Jenkins

Time spent today: 2 hours 30 minutes
Total Time: 26 hours

Hey, all! Welcome to CryptoCL.

After meeting with Dr. Marmorstein, we’re putting in a bit more time into the Hands-On OpenCL tutorials. I’m still working toward solving Exercise 09 — using the given solutions in the git repository.

Going through and implementing the solution, I’m running into an issue with some of the command that the solution uses. The commands are a function called “getWorkGroupInfo”, called by the kernel, and “getInfo” called by the OpenCL device. It seems to think that getWorkGroupInfo has no matching function, but this is not true since the solution calls this function. The second error, however, might be an issue that DEVICE is a defined variable, and does not match the cl::Device object that calls the function. I have some ideas in mind to fix it, but that is for another day.

I’ll continue to work on these throughout the week, until I meet with Marmorstein about designing our cryptographic algorithm to use that is compatible with OpenCL.

Until next time!

Kyle Jenkins

Time spent today: 2 hours
Total Time: 23 hours 30 minutes

Hey, all! Welcome to CryptoCL.

Today, I logged into the lab system to work on the Exercises of the Hands-On OpenCL tutorial. I made some progress into Exercise #09, and have an implementation written, but the program currently results in a segmentation fault. I had only a little time to work on it, since I had other errands to run and the weather was poor, but once I can fix the errors in my implementation, I can work to refine the code and have it pass the exercise.

As far as actual work, it was a slow day, but I feel it was a good day.

See you next time!

Kyle Jenkins

Time spent today: 1 hour 15 minutes
Total Time: 21 hours 30 minutes

Hey, all! Welcome to CryptoCL.

Today, I made some progress on my Hands-On OpenCL exercises and met with Dr. Marmorstein about what’s next for the project.

The issue I was having with Exercise #07 was that I had assumed that the code I was given was a base for what I needed to do, and was correct. This was a wrong assumption, as a cl::NDRange variable called global, which states what the dimension range of the given arguments for the kernel function, was incorrect*. It was set to be a two-dimensional variable, wherein it was supposed to be one-dimensional. After setting it to be one-dimensional of size N, and then declaring a cl::NDRange local variable of size N divided by 16, which means it would be 64 (as N is size 1024). For Exercise #07, I also needed to store the values of the A matrix to private memory. This saw an x4 improvement to the OpenCL portion of the program, compared to Exercise #06.

Exercise #08, on the other hand, utilized the local memory declaration, and called for me to store the B matrix to local memory. This further increased the time.

*Note: As I am writing this post, I believe this implementation may be wrong, as these matrices are two-dimensional. I will have to look at these exercises again and make sure.

Now reaching Exercise #09, I met with Dr. Marmorstein about what the plan would be for this week. The goal is to continue through the exercises, and then next week we will continue attempting to take what we learned into the BLAKE2 implementation, however, the chances are that we will utilize a custom cryptograph, instead. The custom hash would be able to excel with confusion, where the ciphertext and key become so scrambled and altered that it is difficult to establish a relationship between them, using OpenCL. However, the hash would have a difficult time with diffusion, in which each byte of the plaintext should equate to a portion of the ciphertext (and change the ciphertext if changed).

Over this week, I will be continuing with my exercises, and will post my progress as I do so. Thank you for reading!

Kyle Jenkins

Time spent today: 1 hour 15 minutes
Total Time: 20 hours 15 minutes

Hey, all! Welcome back to CryptoCL.

Today I continued my work on the Hands-On OpenCL tutorial. I didn’t make much headway, since I was busy juggling another project that needed more urgent attention along with these tutorials.

Last time, I was having trouble with Exercise 06. I was able to figure out that issue and solve it, as the code that was given was causing issue. Perhaps they were in anticipation for systems with multiple Devices? Simply commenting out that code fixed the issue, and I replaced it by defining a DEVICE variable that sets the device type to default. After that issue was fixed, the program runs the sequential calculation well, but then is unable to solve the OpenCL computation. I was stuck on this for an hour, until I noticed that the kernel source code did not have an implementation. I wrote an implementation, but found it wasn’t the correct implementation. The Hands-On OpenCL git repository actually provides an implementation in a presentation slideshow file. Once implemented, the code now correctly calculates vector multiplication matrices!

I moved on to Exercise07, where the goal is to calculate vector multiplication matrices by row, instead of at row x and column y. I edited the kernel source, but was unable to get the exercise working.

Next time, I will continue working on my exercises. Dr. Marmorstein has been sick for the week, so we might or might not meet tomorrow. Until next time!

Kyle Jenkins.

Time spent today: 3 hours
Total Time: 19 hours

Hey, all! Welcome to CryptoCL.

Today, I did a few of the Exercises in the Hands-On OpenCL tutorial mentioned yesterday. I’ve done every tutorial up to and stopped at Exercise #6.

The first two tutorials were mostly to check your system to see if you were able to run OpenCL on your system. Exercise #3 had you analyze a given program and understand what is happening within the program — it was adding two vectors together, and would return how many passed and would also return any equations that were wrong.

The fourth one is where things would get tricky. It was the same program, but they wanted you to run the program 3 times, adding vectors D, E, F, and G. First you would find C = A + B, then D = C + E, and finally return F = D + G. I ran the same function three times, except I replaced the inputs with the inputs I needed, and changed C and D to Read and Write. Eventually, I got the program to work after also changing places where I was supposed to return C values to be places I return F values.

The fifth one, I feel, was easier than the fourth exercise. In the fifth exercise, you had to change the program and kernel to add an additional vector, which I named D. Nothing was entirely complicated about it — the only thing I needed to do was add the D vector to wherever I needed it.

I stopped at the sixth exercise, which will require me to create an OpenCL program from scratch to multiply vectors. However, using the previous programs as a base, I think this exercise will be easy.

Next time, I’ll talk more about the upcoming Exercises in the tutorial. Stay tuned!

Kyle Jenkins.

Time spent today: 1 hour 15 minutes
Total Time: 16 hours

Hey, all. Welcome to CryptoCL!

I met with Dr. Marmorstein yesterday. We discussed what we had developed toward OpenCL implementation of BLAKE2. Dr. Marmorstein was quite a bit further than I with his BLAKE2b implementation, but also ran into an issue. His issue was that the size of data he was trying to give was still too small. It was still larger than mine, which was at 100000, but still too small for the operations we were trying to accomplish.

We made the decision to go back to doing tutorials. Earlier in the project development, Dr. Marmorstein found a tutorial called “Hands On OpenCL“, written by Simon McIntosh-Smith and Tom Deakin. The goal of the tutorial is to provide exercises to educate on how OpenCL works. After taking a look at the files, it does seem like a very useful and effective way to learn OpenCL. We decided to spend the week working on these exercises.

This week will definitely be much more tame than the last week or so of development time, but will be essential in exercising and testing our understanding of the OpenCL standard. Expect the next few posts to be about the tutorial.

Thank you, and see you next time!

Kyle Jenkins.

Time spent today: 1 hour
Total Time: 14 hours 45 minutes

Hi, all. Welcome to CryptoCL.

Firstly, the name change. I think the name change was a matter of time. I’m a bit disappointed it’s not a complete acronym, but I think there will be… less problems with this new one, so that should definitely outweigh the cons.

Now for the actual content of the blogpost — today I had begun implementing the Rob Farber tutorial. An interesting difference from the Erik Smistad tutorial from previous posts is that, besides being in C++/C respectively, Farber chose to implement his kernel source code as a constant character array, rather than its own file. I think I prefer Smistad’s method, however, as that will keep the kernel files separate from the main files and easier to find.

The same issue of the clCreateCommandQueue function call being deprecated in Smistad’s tutorial was also present in Farber’s tutorial, and was simply fixed the same way as last time — by adding “WithProperites” to the end of the function call name. I also ran into a simple bug where I forgot to include the stdc++ library in my compile command call.

The program now compiles and runs. However, the results are not what I expected it to be — this may just be an issue with the remote access, and needs to be tested physically. I double-checked by running Smistad’s test remotely, which also didn’t work correctly.

By the next blog post, I will run the program to make sure things are running smoothly. I will also begin with the actual implementation of BLAKE. We are deciding which version of BLAKE2 to implement — either BLAKE2b or BLAKE2s. 2b is optimized for 64-bit platforms, while 2s handles 8- and 32-bit platforms, as explained by the BLAKE2 RFC under 1. Introduction and Terminology. We may even implement both!

See you next time, and thank you for reading!

Kyle Jenkins.

Time spent today: 1 hour 15 minutes
Total Time: 6 hours 15 minutes

Hi, all. Welcome back to ICOC.

Today was a somewhat slow day. I decided to do a little bit of work towards the project, but not much — mostly some research.

However, Dr. Marmorstein contacted me about the driver update, and while the drivers were finished with the update, the error that was causing the Erik Smistad tutorial to fail was not an issue with the driver, but a bug in the program. The output vector, C, was accidentally given the const prefix. After that was fixed, the program ran correctly. Every print out of the program, where each element of A at i was incrementing by 1 from 0 until 1024, and every element of B at i was decrementing by 1 from 1024 until 0, equated to 1024.

I had begun looking into the other tutorial from Rob Farber, when Dr. Marmorstein shared with me a GitHub repository from a user whr, entitled “clblake.” It appears to be a very similar project to the one being conducted here, except rather than using BLAKE2, whr chose to use BLAKE256, instead. Regardless, given how closely the project resembles ours, we’re adding whr’s clblake repository as a “Previous Work” credit.

That was everything done today. Again, a shorter day, but next time, I will be implementing the Rob Farber tutorial as my second and final tutorial. Then, it’s time to start with the real project!

Thank you, and see you next time!

Kyle Jenkins.

Time spent today: 1 hour
Total Time: 5 hours

Hi, all, welcome back to ICOC.

On the agenda today was scouring the web for tutorials to get familiarized with the OpenCL standard, and so far, I’ve found two tutorials that I want to try. One tutorial was written by a members of the Khronos Group, Rob Farber (which we’ll talk about later, but here’s a link now.), while the other was written by Erik Smistad.

The first tutorial I decided to implement was the one written by Erik Smistad, titled “Getting started with OpenGL and GPU computing.” This was an example that Dr. Marmorstein highlighted as we were forming the research project. The tutorial aims to add vectors contents together. While this can be done easily with a simple for loop, Smistad chooses to implement it using the OpenCL standard to allow for GPU computing. This will decrease the time it takes to compute the vector addition from linear, or O(n) with n being the size of the vectors, to relying on the number of cores in the processor instead, which can speed up the computation time.

Following Smistad’s guide, I was able to replicate this vectorAddition program, having created a main program and a kernel program to which the computation would occur in the GPU. The only issues that needed to be addressed were the facts that the OpenCL function “clCreateCommandQueue” is deprecated, and needed to be replaced with “clCreateCommandQueueWithProperties”, and the fact that the lab system I was using did not have an updated driver. Dr. Marmorstein is updating the drivers in all of the lab systems, which should fix that problem. Thankfully, one of the lab systems had the driver partially installed, so a remote login allowed me to compile the program.

Running the program, another problem appeared — when the program runs, the program will print out the given item at i in both vectors A and B, add them together, and print the result C in one line. However, all of the additions are wrong. They are either zero, or a ridiculously high number. At the moment, this does not appear to be user error, as Dr. Marmorstein was able to confirm the error, as well. Here’s hoping that the driver update will help this error somewhat…

That being said, that is all of the progress today. Tomorrow will be a day to work on more research and make sure that this tutorial is completed successfully.

Thank you, and see you next time!

Kyle Jenkins.

Time spent today: 1 hour 15 minutes
Total Time: 4 hours