Implementing Cryptography with OpenCL

Hey, all! Welcome to CryptoCL.

Over the past several days, I had tried to develop the new cryptographic hash. However, with being very busy with other assignments, I was unable to get very far in my efforts. I kept getting stuck on mistakes that I think a more fresh eyes and fingers could fix much more quickly than I could.

However, that isn’t to say I’m not proud of my work. I was able to strive to develop something new — something that might have not been made before. Although I couldn’t finish, I am certain that it would help me in the long run.

With this experience nearly wrapping up, I have to present my findings in a presentation. I found that it is possible to implement OpenCL into BLAKE2, but doing so with greatly affect the performance of the hashing algorithm. Moreover, the OpenCL standard would not be fully utilized — as BLAKE 2 is sequential in nature.

By the end of the week, I will post my next, and final, post to this blog. I will discuss in greater detail my findings and thoughts on this project.

Thank you for reading!

Kyle Jenkins

Time spent today: 4 hours 30 minutes
Total Time: 40 hours 30 minutes

Hey, all! Welcome to CryptoCL.

I showed Dr. Marmorstein my cryptographic hash. It seems that the permutation step was not actually permutation, but a complicated substitution step. I have since written a simple permutation step.

When I ran the program with user input, the program would spit out undecipherable garbage. However, I was told this is a good thing, so I will keep it.

I have since begun to write a program to calculate the confusion. However, given how I’m writing it, it would seem I would need to do a complete overhaul of my program in order to do this. I am not looking forward to this, and it feels like a lot and I’m not sure where to go with it.

I will keep trying, but if I can’t make a successful breakthrough by the weekend, I am most likely just try and implement the program using the OpenCL standard, so that I have at least a working OpenCL program.

Kyle Jenkins.

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

Hey, all! Welcome to CryptoCL.

The cryptographic hash algorithm is complete. It’s not the best or most secure, but the input is being successfully encrypted.

I changed my permutation algorithm to check the substituted number. If the number is between 64 and 91 (A-Z in ASCII), then the value of the unsigned int pointer n at i will be changed to the BLAKE2s SIGMA value at row i mod 10, and column of the value of the unsigned int pointer o mod 16 + 64. This plus 64 will help the new value of n at i to be at least A. Otherwise, it’s the same value of BLAKE2s SIGMA, but with an addition 96.

The program now splits the message into 16 byte blocks, substitutes each individual byte, permutes each byte, and substitutes again, and repeats until finally printing out the result.

One issue that arises of the algorithm security-wise is that, when the remaining bytes are zeroed out, and whenever you run the program with zeroed out bytes, you will easily be able to see which bytes are zeroes. There’s a specific pattern that appears regardless of the message at the end of the last 16 byte block with zeroes.

However, I am quite proud of my algorithm. Although it’s not the best, the letters are changed depending on their location, which means it will be difficult to crack in a marginally short amount of time, at least by hand.

Tomorrow, I am speaking with Dr. Marmorstein to discuss incorporating OpenCL into the algorithm. I feel pretty good about this!

Until next time!

Kyle Jenkins

Time spent today: 1 hour 30 minutes
Total Time: 33 hours 30 minutes

Hey, all! Welcome to CryptoCL.

Progress on the new Cryptographic hash is slow going. I am working to try and implement the non-OpenCL implementation by Monday.

Right now, I have the substitution and permutation functions defined. The substitution function is a simple one, where you return the given unsigned char + 1 and modulate by 256.

The permutation function, however, is causing the most problems. I want to implement the BLAKE2s SIGMA variable if possible. The B2s SIGMA is a large 10×16 uint8_t variable, mapping numbers of 0 to 15 to each of the 10 rows:

static const uint8_t blake2s_sigma[10][16] =
{
{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 } ,
{ 14, 10, 4, 8, 9, 15, 13, 6, 1, 12, 0, 2, 11, 7, 5, 3 } ,
{ 11, 8, 12, 0, 5, 2, 15, 13, 10, 14, 3, 6, 7, 1, 9, 4 } ,
{ 7, 9, 3, 1, 13, 12, 11, 14, 2, 6, 5, 10, 4, 0, 15, 8 } ,
{ 9, 0, 5, 7, 2, 4, 10, 15, 14, 1, 11, 12, 6, 8, 3, 13 } ,
{ 2, 12, 6, 10, 0, 11, 8, 3, 4, 13, 7, 5, 15, 14, 1, 9 } ,
{ 12, 5, 1, 15, 14, 13, 4, 10, 0, 7, 6, 3, 9, 2, 8, 11 } ,
{ 13, 11, 7, 14, 12, 1, 3, 9, 5, 0, 15, 4, 8, 6, 2, 10 } ,
{ 6, 15, 14, 9, 11, 3, 0, 8, 12, 2, 13, 7, 1, 4, 10, 5 } ,
{ 10, 2, 8, 4, 7, 6, 1, 5, 15, 11, 9, 14, 3, 12, 13 , 0 } ,
};

However, it seems to be causing some problems — more specifically, it seems that attempts to substitute after the permutation (a test to see if the code is currently working) only spit out garbage.

I will continue to work on improving the algorithm. The hope is to have it in working order by Monday, then, OpenCL implementation is the next step. Thank you!

Kyle Jenkins.

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

Hey, all! Welcome to CryptoCL — and I hope you had a Happy Halloween!

Today, I began implementing our own Cryptographic Hash. The goal it take a given message, split it into 16 bytes (and adding filler to the remainder bytes to make it size 16), and split it further into 1 byte blocks. We then take the 1 byte blocks and perform a substitution and permutation equation onto it. Next, we combine the 1-byte block with the next 1-byte block, so we have all 2-byte blocks, and perform another substitution along with transposition function. We continue this by combining into 4, 8, and then back to 16. Once we’re back to 16-byte blocks, we’ll XOR this block with the next block, and repeat until we reach the end of the message.

At the moment, I have a simple implementation of the basic algorithm. There is no substitution, permutation, or transposition algorithms yet — that will come later. There is also no OpenCL code yet, as I wanted to get the basic algorithm finished before I started using the OpenCL standard.

Next time, I have a meeting with Dr. Marmorstein, and we will most likely discuss how to improve the code and how to make the functions unique.

Until next time!

Kyle Jenkins

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

Hello, all! Welcome to CryptoCL.

Firstly, thank you for joining me on Day 10 of CryptoCL. Every day I work on CryptoCL, I log my progress and thoughts, and I’m glad you all are joining me on this ongoing project. Thank you!

Back on topic, Implementation of OpenCL into BLAKE2s continues. I managed to find a slight workaround for the issue I stopped on, which is to simply set the second argument as 0. While in the main function, the argument is supposed to be 0-7 for all 8 instances of G being called, I’m only going to work on one instance, until things work. I just have the result of the kernel operation stored into “part” variables, from p1-p4, for v[0], v[4], v[8], v[12], respectively. Then, I free up the memory these cl objects take up within ROUND and main once I”m done.

Issues I’ve run into today is an issue of needing to make new definitions of blake2s functions. The function blake2s_compress is easy to fix, as that is declared and defined within the new blake2s-ref-driver.c file. However, functions like blake2s_init_key, blake2s_update, blake2s_final, and blake2s are declared in the blake2.h file. I could redefine them, but that would break other files within the directory that rely on those functions. I chose to copy those functions and make new definitions, which differ from the original to include the OpenCL objects (Like cl_context and cl_kernel) and the “_driver” suffix.

I was running into an issue on compiling, where the compiler couldn’t recognize OpenCL functions — but then I remembered I ran into this issue already, and included the OpenCL library in my make file.

The compiler is still having an issue at the moment — there’s an undefined reference to main. I don’t use makefiles often, and this seems to be an issue with being unable to make an output file. I will take a look tomorrow.

Next time, it will be time to finish the implementation and start bug hunting.

Thank you again for 10 days! See you next time!

Kyle Jenkins.

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

Hey all, welcome to CryptoCL.

After talking with Dr. Marmorstein, we both decided we will both use one version of BLAKE2 to implement using OpenCL. I am tasked to implement OpenCL with the BLAKE2s version of BLAKE2.

However, I was a bit confused about our last meeting — I mistook my work to be to implement the ROUND function as an OpenCL kernel. This was a mistake, as I needed to implement the G function as the OpenCL kernel. After a quick fix, I began to implement various OpenCL functions into the BLAKE2s implementation.

I had a choice to make in whether or not I should start creating OpenCL objects in the main function, or later on in the ROUND function. Doing the former means that the program will be quick to end if there is an issue with building the kernel, however these variables will have to be carried from the main all the way to wherever the ROUND function is declared. Doing the latter meant that, while everything was concisely packed into the ROUND function, the program would have travelled pretty far already, and be difficult to manage the memory safely. Weighing the options, I opted for the latter, and decided to create the OpenCL objects within the main function.

Memory objects that were to be used by the kernel, however, will be created within the ROUND function, and disposed of at the end of the ROUND function.

I decided to stop in the middle of my work after looking over it for a long while, and since I have other obligations to do, stopping at the point where the kernel arguments were being assigned to the function. I stopped at a good place, too — the G function takes in an unsigned int i, which is the numbers 0-7 within the ROUND function. I might need to understand more of how OpenCL works, because I am not quite sure how to implement this as a argument for the kernel. I’ll do some more research to find out, and continue next time.

Next time, I should be able to finish implementation of the OpenCL version of BLAKE2s, and then it will be time to fix errors or bugs (but in an ideal world, the program has no errors and bugs and I can move onto testing, but this is not the likely outcome!)

See you next time!

Kyle Jenkins.

Time spent today: 3 hours
Total Time: 12 hours

Hello, all! Welcome to CryptoCL.

Today, I completed implementing BLAKE2b and BLAKE2s. It appears that, although I cannot accurately tell what is happening when running the programs, they do successfully work.

I met with Dr. Marmorstein yesterday to discuss our next move. We explored through the code, and ran into an issue — a core function of BLAKE2, known as function G, runs sequentially. On the outset of a normal program, this is not an issue. However, for OpenCL, this is grave news. As discussed earlier, OpenCL is used to allow for parallelism. However, since the hash function for BLAKE2 requires values to be updated and then used elsewhere within the same function, it is impossible to be able to run the function in parallel, as information would not be properly updated or even overwritten.

We decided to try and brainstorm a new plan of action. In the meantime, I worked to implement the ROUND function as OpenCL kernels. ROUND calls the function G eight times — the first four and the second four are independent from each other. Ergo, we believe that if we run this function as two kernels for each half of the ROUND function, we can at least achieve some form of parallelism.

For both BLAKE2b and BLAKE2s, I implemented two files for each called “blake2?_round(x)_kernel.cl”, where ? indicates either b or s, and x signals 1 or 2 for the top or bottom half of the ROUND function, respectively. These functions are basically untouched from how they are presented in the original function — just now the function has a __kernel prefix and all variables have a __global prefix.

Next time, I will meet with Dr. Marmorstein to discuss where to go next with this project — chances are, we will design our own, primitive cryptographic hashing algorithm to implement that will be able to run in parallel. One idea is run operations of pieces of the input in parallel, combining the results together until we get the encrypted message.

Until then, have a good night!

Kyle Jenkins.

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

Hi, all! Welcome to CryptoCL.

Firstly, an update on the issue with the Rob Farber tutorial: After testing it on the lab system, the program successfully ran and passed all the tests. The lab systems have support for OpenCL, while my system at home does not. Ergo, using the lab systems to handle programs that deal with OpenCL will be crucial.

Next, BLAKE2 implementation has begun! Firstly, we are grabbing from the BLAKE2b and BLAKE2s (abbreviated as B2b and B2s hereafter) implementations provided from the BLAKE2 git repository. After browsing the code, I compiled both versions of B2b and B2s (One version specializes in speed, while the other complements portability and simplicity, as stated in the README). They all compiled and ran successfully, at least from what I can tell — looking through the code shows that the program prints “ok” when it runs without errors.

The problem is that the code doesn’t give an other information. When testing cryptographic functions, I would usually input some sort of input or the like, and compare to what the answer is supposed to be. However, the implementation provided does not given any other information besides if the program was successful in running.

Tomorrow, I will continue looking through the code. One, to study the implementation for the OpenCL-compatible version, and to see how I can accurately test the code.

Have a good day!

Kyle Jenkins.

Time spent today: 1 hour
Total Time: 7 hours 15 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