Implementing Cryptography with OpenCL

Hey, all! Welcome to CryptoCL.

Today was a short day of research — I delved deeper into researching the Data Encryption Standard (DES) and Advanced Encryption Standard (AES) cryptographic algorithms. Most of my time went into the AES algorithm, however.

I looked up the FIPS publications for both DES and AES, and also looked into a tutorial of the AES algorithm, to give me a general idea of how the algorithm works. It also helps that I was able to refer to my notes from when I took a Cryptography class.

AES utilizes four main functions:

1. Byte Substitution — Substitute the input (present as a byte) , 16 input bytes at a time.
2. Shift Rows — Shifting the rows of the 16 substituted byte input to the left.
3. Mix Columns — Takes each column of the 16 byte substituted and shifted input, and transforms them based off a given function.
4. Add Round Key — Take the 16 substituted, shifted, and mixed input bytes, translated them to 128 bits, and XOR them by the 128 bit round key.

Normally, this operation could take a very long time to process, especially with larger messages or data. That being said, I believe that OpenCL could easily split up the four functions for each 16 byte input into independent operations to be done by the GPU. As discovered when first attempting to implement OpenCL, the standard cannot be utilized effectively when the input is being overwritten in the kernel and then used elsewhere within the same function. However, functions 1, 2, and 4 do not utilize overwritten other parts of the input when calculating the output in each function, so this should allow OpenCL to optimize the calculation.

Tomorrow, I will look over my projects I had written when taking the Cryptography class, and get a better look at how AES operates.

Until next time!

Kyle Jenkins

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

Hey, all! Welcome to CryptoCL.

I spoke with Dr. Marmorstein very briefly last Friday about the research I had done on clblake. I’m going to add my notes onto the previous blogpost. Again, they’re just notes that try and make sense of what is going on under the hood of the program.

More importantly, I started to do some research in an attempt to develop our own Cryptographic hashing algorithm. As a short and sweet refresher on Cryptographic algorithms, I found a website called Crypto-IT that discusses how certain algorithms work. I determined that the best kind of algorithm to use would probably be some form of Block Cipher. This is so that we can easily split up the given message into blocks, and perform the encryption or decryption with every block. This would definitely not be a secure algorithm, most likely, as we would probably have to use one constant key for each block. However, as far as speed is concerned, it should definitely speed up the algorithm by removing the tedium of processing each block once at a time.

There is still more studying to be done! I plan to look more in-depth into the AES and DES algorithms, as they are block algorithms and were (and still are) widely used.

See you next time!

Kyle Jenkins.

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

Hey all! Welcome to CryptoCL.

A bit of a short day today, as far as this research project, at least. I spent about an hour to 90 minutes researching clblake. I went through the program and looked at how wfr was able to accomplish parallelism with BLAKE256. A lot of the code is setting up things for the program to utilize and calculate into the hashing function. A lot of blake256 functions were also translated into the blake256.cl file, to be used by the kernel. There is a lot of moving parts when it comes to this blake256 implementation.

Tomorrow, I will discuss with Dr. Marmorstein about the notes I took, and figure out where to go from there.

Thank you!

Kyle Jenkins.

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

Edit 10/20/2020: Here are the notes I took on the clblake project:

Loading...

Taking too long?

Reload document

| Open in new tab

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!

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 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

Hello, and again, welcome to Implementing Cryptography with OpenCL, or ICOC for short!

I am Kyle Jenkins, and I am tackling this project to gain more experience in programming in the graphical interface. The goal of the project is to implement a cryptographic hash in a graphic environment, rather than in the CPU, in order to encrypt and decrypt values. To do this, I will be using OpenCL and using the BLAKE2 hash function.

Open Computing Language, or OpenCL, is an open-source standard that allows for parallel and cross-platform programming. This standard will allow for a connection between the CPU and the graphical environments. This will be necessary to activate the cryptographic hash function that will be processed within the graphics card.

BLAKE2 is a cryptographic hash function that is at least as secure as and faster than SHA-3, another cryptographic hash function. It is also one of the hashing components of Wireguard, a VPN service. The BLAKE2 function will be implemented so that it will be processed using OpenCL in the graphics card.

The final goal is to be able to accurately write a complete algorithm that will hash values using the BLAKE2 function through the graphics card, using OpenCL as the parallel programming standard, and encrypt/decrypt the input into an output. The algorithm would first begin on the CPU with an input of the values to encrypt or decrypt. Then, the algorithm would call functions written to be processed within the graphical environment and create a BLAKE2 hash. Finally, the graphical environment would take the input and, using the hash, encrypt or decrypt the input and return the results as the output, back onto the CPU.

This blog will be where I post my progress as I research and develop this algorithm. Here, I will post results of my research, studies, and progress toward the algorithm. You can expect at the very least two posts during the business week and one post during the weekend!

Thank you for your interest in my project!

Sincerely,
Kyle Jenkins.