As you’re not aware, a few months ago I wrote a simple server/client for changing Alsa volumes from another computer, or an Android phone. I’ve been extremely slowly working on adding encryption to it, but unfortunately, jobs and school come before hacking away at projects. Regardless, one downfall of the project has always been that I could change the volume, but I couldn’t play/pause music. All the programs I’ve seen to do this have been media player plugins that are, obviously, specific to that media player only. As someone that changes media players somewhat frequently I didn’t want to go down the road of writing a plugin for one player. Then it hit me, why not have my server simulate media key presses from the keyboard in X11? This would work for any media player that supported media keys and since I already have the server written, it’s only a matter of modifying the protocol to accept more commands and add a function to simulate key presses. However, first I needed to figure out how to simulate key presses. It turns out it’s very easy. Let’s jump right into the code.

Disclaimer: I am NOT a crypto expert. Don’t take the information here as 100% correct; you should verify it yourself. You are dangerously bad at crypto.

This post details the EVP functions for RSA. If you’re looking for a pure RSA implementation or want something in C rather than C++, see my other post on this.

In my seemingly endless side project to implement RSA and AES encryption to my Alsa Server project, I wrote a while ago about doing simple RSA encryption with OpenSSL. Now, I’m here to say that I was doing it all wrong. In my first post about RSA encryption and OpenSSL my code was using the low level RSA functions when I should have been using the high level EVP (envelope) functions, which are much nicer to work with once you get the hang of them.

Being that this code is eventually going to be merged in my Alsa server project, I went ahead and also implemented AES encryption/decryption and put everything in an easy to use C++ class.

I assume that readers are familiar with encryption and OpenSSL terminology (things like IV, key lengths, public vs private keys, etc.). If not, look it up since there are much better explanations out there than I could write.

Why use the EVP (envelope) functions for RSA encryption rather than the actual RSA functions? Becasue the EVP functions don’t actually encrypt your data with RSA. Rather, they encrypted a symmetric key with RSA and then encrypt your data with the symmetric key. There’s a few reasons for this. The main one being that RSA has a max length limit to how much data can be encrypted at once. Symmetric ciphers do not have this limit. If you want pure RSA, see my post about that, otherwise, you probably want to be using the EVP functions.

Last week I finally bought a second HDD for my home directory so I could have some redundancy in case a drive fails. Lucky for me, I had the foresight to put the single drive I had been using on a RAID1 array all by its lonesome self way back when. After installing my new HDD, I found myself tasked with adding to the array. Simple, right? Yes, but with one caveat.

After installing and partitioning the drive properly, add it to the array with:

1
mdadm --add /dev/mdX /dev/sdXX

Since the array was only set up to have one drive, the new drive will get added as a spare. Check /proc/mdstat to confirm this…

1
2
md4: active raid1 sdb1[1](S) sda1[0]
   1953512312 blocks super 1.2[1/1][U]

This isn’t what I want! Well, here’s the catch: there’s one more (very simple) step; grow the array to the new number of drives.

1
mdadm --grow /dev/mdX --raid-devices=Y

…where Y is the new number of drives. And now, to check /proc/mdstat:

1
2
3
md4 : active raid1 sdb1[1] sda1[0]
      1953512312 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  2.1% (41879104/1953512312) finish=516.9min speed=61630K/sec

Perfect! The new drive is on equal playing field with the existing drive and is being brought up to speed with the data on the existing drive.

Ahh, data redundancy. :)

Hey you! This post is outdated!

Take a look at a more correct, detailed, and useful one. What’s the advantage? The EVP functions do implicit symmetric encryption for you so you don’t get hung up on the max length limitations of RSA. Plus, it has an AES implementation.

Disclaimer: I am NOT a crypto expert. Don’t take the information here as 100% correct; you should verify it yourself. You are dangerously bad at crypto.

Last month I wrapped up my Alsa Volume Control server project. To test it, I exposed the server to my public Internet connection and within a few hours, my friend was using the lack of authentication to change the volume on my computer from his apartment. It may not be a serious security hole, and funny as it may be, it would certainly be annoying if someone had malicious intentions in mind. The simple solution is just disable the port forward so the server is only accessible via my LAN, but what fun is that? What if I feel like changing my volume from anywhere for whatever stupid reason I may have?! Thus, I needed to add authentication to the server, which means I also a needed a way to encrypt credentials as they went over the network. And so I opened up the OpenSSL documentation to figure out how to encrypt and decrypt simple messages with RSA in C. Here’s a quick summary…

First up, to do anything with RSA we need a public/private key pair. I assume the reader knows the basic theory behind RSA so I won’t go into the math inside a key pair. If you’re interested, here’s a good write-up on the math behind RSA.

1
RSA *keypair = RSA_generate_key(2048, 3, NULL, NULL);

Here we’re using the RSA_generate_key function to generate an RSA public and private key which is stored in an RSA struct. The key length is the first parameter; in this case, a pretty secure 2048 bit key (don’t go lower than 1024, or 4096 for the paranoid), and the public exponent (again, not I’m not going into the math here), is the second parameter.

So we have our key pair. Cool. So how do we encrypt something with it?

Just over a month ago the other officers of the Penn State ACM and I were approached by the president of the newly-formed Penn State of Association of Women in Computing to co-host a programming competition which would come to be known as CodePSU. We set the date of the event and had roughly one month to plan everything. Most of the logistical (location, food, times) and financial (sponsors, prizes) were not handled by me. Rather, I tasked myself with designing and implementing a code submission system that allowed teams to upload solutions to problems to the judges. The catch? It had to be fast. We would have three judges judging 60 people’s code multiple times in just three hours. It also had to be secure. We couldn’t allow teams to figure out what test cases we where judging the problems with or allow them to get access to other teams code. If that wasn’t enough, we also had to support C, C++ and Java.