Software Development, Work Projects

Pretty Good Privacy


Shortly after starting with my new company, I began work on a back-end infrastructure project. To be specific, I am working on an inter-process-communication (hereafter IPC) layer. As the project developed, we realized the need to protect our data in transit. This is because we are working with Protect Health Information (hereafter PHI). It would be a disaster if the data became compromised.

So to combat this, we are encrypting the data before it is send through the IPC layer. There are many fine encryption schemes available, but many are difficult to implement. Moreover, it is not enough to just encrypt the data. One cannot continue to use the same key for all applications without risk. Enough messages using the same key, and enough time mean someone could learn it. They would then be free to read all our messages and the possible PHI contained within.

Our brilliant architect suggested that we use Pretty Good Privacy or PGP for short. It is an easy to implement encryption scheme that combines many desirable features. PGP uses a new random key for each message to encrypt the outbound data. This key is itself encrypted by a known private key, and is sent along with the encrypted message.

Since the key is random every time, it is difficult to guess the private key. As a result, one cannot decrypt the public key, thus the message is reasonably safe.

To help explain this, I have crafted a simple example in python code, using a Vigenere Cipher. You can find the entire example project on my GitHub Repo, here. But the core of the example is as follows:

def encodePGP(self,plainMsg): 
# generate random key 

randKey = self._generateRandomKey() 
print("> Internal Random Key: "+randKey) 

# encrypt input with ^ 
cryptographer = Crypto() 
encryptedMsg = cryptographer.encode(randKey,plainMsg) 

# encrypt random key with priv. 
key pubKey = cryptographer.encode(self.privateKey,randKey) 

#return concat encrypted key and input 
return pubKey + "_"+encryptedMsg

For those who prefer, a visual representation of this is available on the Wikipedia page for PGP. The algorithm is as I stated before:

  1. Generate a Random Key for the message
  2. Encrypt the message with the Random key
  3. Encrypt the Random Key with the Private Key, to form the public key
  4. Concatenate the Encrypted Message and Public Key

The code for Decoding is as follows:

def decodePGP(self,concatMsg): 
#parse encrypted pub key, encrypted message 
parsed = concatMsg.split("_") 
pubKey = parsed[0] 
encryptedMsg = parsed[1] 

# decrypt rand key with priv. key 
cryptographer = Crypto() 
randKey = cryptographer.decode(self.privateKey, pubKey)
# decrypt message with rand key 
decryptedMsg = cryptographer.decode(randKey,encryptedMsg) 

#return message 
return decryptedMsg

In plain terms the decryption steps are:

  1. Parse the input message to get the Public Key and the Encrypted Message
  2. Decrypt the Public key with the Private key, to form the original Random Key
  3. Use the Random Key to Decrypt the Encrypted Message

Ridiculously simple right?! However, this method can be rendered vulnerable by using a weak encryption method, such as the Vigenere Cipher, as I have. Though,it should be clear that a PGP-Vigenere is stronger that Vigenere alone.

As you can see, with a strong encryption method, PGP adds a significant increase in security. The cost is that it increases the complexity in a limited fashion. Naturally, I will be adding this to my tool kit for future projects! I hope this explanation and example has been helpful. But I admit the diagram on Wikipedia provides a good outline of the PGP scheme. For anyone interested, you can download the example and the Vigenere Cipher implementation here.

Software Development, Work Projects

Licensing Overhaul – Return of the Designer


In case you missed parts one or two of the series you can find there here: Part 1- A New Challenge, Part 2 – The Whiteboard Strikes Back

Welcome back to the series on Licensing Overhaul! Last time we witness the rise of a new system, and discussed the gritty details of some of the more important components. This time we will review our journey, and focus more on some realizations brought on by hindsight.

To summarize, my PM wanted to change what some of the existing Licenses allowed our users to do. So I spend some 6 weeks digging through the old jungle of code, and developed a simpler, and in my opinion cleaner solution.  Last week, I went into detail about this design. This week I plan to cover the benefits that were realized in the design as well as some of the foreseen drawbacks. I will address the drawbacks first.

Every decision made in a design naturally chooses a set of advantages and disadvantages to take for the software. My new licensing system is no different in this respect. While the design supports a great number of data types to query, it is somewhat weak in this area.

Specifically the performance of the query may be adversely affected should the number of datatypes be greatly increased. Thankfully, the number necessary would be very great indeed. Each License would need to support something on the order of 10,000 different data types before any notable performance hit would be noticed.

This weakness results from the License Checking each ObjectType for its data type. This could be easily fixed if the License were to use a data type to Permissions dictionary rather than a simple list. However time has not yet been allocated to for this change, and the solution was not discovered until after the project was determined to be complete.

In a similar way, the number of Licenses may also present certain challenges. Since each License is queried for each permission request, if the number of different licenses checked out by the system should increase greatly, it would also negatively impact the performance of the query.

Again, the number would need to be very great, on the order of 10,000. However, the number of License checks has a multiplicative effect on the ObjectType check. As a result, it would probably be best to spend the time to fix the ObjectType rather than the License check bottleneck, as this would offer greater improvement between the two.

So much for the weaknesses of the design. Now on a happier note, the design has several strong benefits, some were realized very early on in the implementation, while others became apparent towards the end. I will start with the one which became obvious while I was implementing this change.

Perhaps the most long lasting of the benefits for the new system is that it was built to support incremental changes! The new system did not completely replace the existing License checks, rather it came in along side them and took over a select few. By doing so, the scope of responsibility remained manageable during implementation, and it only touched what it had to. This benefit was by far the biggest in terms of controlling scope creep.

The next benefit became obvious as I drew to the end of the project. By that time, the accumulation of permissions knowledge grew to such a size that it was easy to see the patterns of allowance by the licenses, at least for the affected area of data. Since we now had an aggregation of the License permissions knowledge, future changes to said permissions are much simpler. Rather than having to dig through many thousands of lines of code to replace the various license checks, one would need only change how the License Object was created in order to implement the desired change.

To cap things off, I realized that there was one further benefit that could be realized. However this will likely not be until the remote future. At present the Mediator relies on the Manager to determine what Licenses are checked out. Presuming that any replacement manager implements the same interface, it can easily be swapped out when the time comes. And with the code base gradually moving towards C#, it seems that it may be inevitable, albeit sometime in the next 20 or more years.


All in all, this was a very enlightening project to be allowed to work on, and very rewarding for the chance to implement a system which may one day widely affect the application in the future. Naturally there are some optimizations that I could chosen had I been thinking about performance, but it has been said that premature optimization is the root of all evil.

As always, I thank you for listening and I welcome your thoughts and comments! Let me know if you think of any ways to improve the design, I would really enjoy such a discussion! And until next time, good luck and God bless!

  • Bottleneck road sign –
  • Library Interior –
Software Development, Work Projects

Licensing Overhaul – The Whiteboard Strikes Back



In case you missed it, you can see Part 1 of the series here: Part 1 – A New Challenge

Last week, I introduced my second biggest work project to date. Shortly after re-vamping the License structure, my PM decided he also wanted to change what some of the licenses allowed the user to do. Upon digging into the code, I discovered a tangled web of multiple checks and confusion. I thought there was no way I could finish in 10 weeks. Thankfully my estimates were in correct, and some solid design work saved the day! Today, I will discuss the design aspects of my new implementation.

Starting out, I knew this project would be not only big and rather difficult but that it would also be a catastrophe later if I did not do it well. Even so I was surprised by just how ornery the project got before the end.

To be certain, I knew at the outset that I wanted my design to be better and if possible to be more Object-Oriented that the previous implementations had been. However I had very little idea what that meant at the time.

As I progressed through the project some goals did eventually become apparent. I am listing them here, in the hopes that I might learn to generate these design goals earlier in the project going forward.

  • I wanted my design to provide an explanatory interface to the user. I wanted it to be clear from looking at a simple call what permission was desired.
  •  I wanted permissions presented to be general enough that only a few would be needed, and that these would be clear in their intent.
  • I wanted to ensure that any code written in this phase was stable enough that it wouldn’t change should any new scope be added. To be more specific, if the covered permissions or the data types that were covered ever increased I wanted the present code to remain unchanged, both in syntax and in outcome.
  • I wanted my code to be segregated enough that if ever the original License Manager need be replaced, it would be done with a minimal effort to update the new code base, and without disturbing the Permission request calls listed above.
  • Lastly, I wanted my new code to be easy for anyone who came after to learn and to use, so as to reduce the multiple versions of the same License check that were seen in previous implementations.

Again, I admit that these goals were not all so verbose when I started the project, but I did set out with something very like this in mind as I began to design my solution.

During the first few weeks of the project, I spend a great deal of time sifting through the code, concentrating on the Main UI area, and on the areas which my PM had mentioned he wanted to change. I made note of the patterns, and anti-patterns that I found throughout, and used these to inform my design choices.

While sorting through all of that information, I also spend a lot of time at a whiteboard drafting, and redrafting the objects and responsibilities that I wanted to manage, in order to solve the problem.Overall a great deal of attention as spend on their interfaces. The picture below shows the resulting system that I developed, as drawn on a whiteboard.


The workhorse of my solution was the Mediator, which was responsible for routing the Permission Request from any end point through the licenses that the system currently had checked out, and provide a Boolean response to either allow the request or to deny it.

To facilitate its work, it is injected with the License Manager, which is used to determine what Licenses, if any, are presently checked out for the system, and then it called on the Factory. The Factory, per its namesake, would create License Objects prepared to answer the Request queries being routed to them by the Mediator.

All of this architecture was created to support the abstraction of the idea of a Permission, that is an allowed action on a particular data type. A License in this sense, is composed by the series of Data types and their allowed actions under that License.  The Connection between Data Type and Action Type are represented by the Object Type object.

Now, some of the more seasoned developers reading this will probably be shaking their head at this name, but I assure you there was a good reason for it. In the first place, the code base I had to work with had another meaning for the term ‘data type’ and as a result the only other suitable term that myself, and an English major could conjure up that meant something similar to our intention was ‘object’.

Getting back on topic, there are several classes where a 1 to N relationship is specified. In laymen’s terms, this means that it is possible for multiple of the ‘N’ type objects to housed under the ‘1’ type object. This is a oversimplification, it will suffice for the moment.

The reason there are several 1 to N relationships is because I wanted to abstract the responsibility for know whether or not a particular action was allowed, while simultaneously providing a simple and easy to use interface for such a query. What I ended up creating is best show by the “call-stack-like” write up shown in the picture below:


As I mentioned earlier, the Mediator would route the query to the Licenses which were checked out at the time. So each license is asked whether or not it supports the requested action. To determine this, each License will in turn find the matching Object type of the query, if it has one, and will further route the request. The ObjectType then response based on whether or not it has permission for that action.

Since the number of licenses is unknown, some additional check are needed. For example, it makes sense to just skip the checks if no licenses are checked out, since there would be no response. However if multiple licenses are present, then some rationalizing needs to be done on their multiple responses. Thankfully, the PM decided that it was sufficient to allow the action if at least one of the Licenses that was checked out allowed it.

That is really all the more complex it got. After the appropriate associations were made to the various license. This basically concludes the design portions, and data types, it was a simple matter of tracking down what code I needed to change and how.

Admittedly, that process took nearly a month, and would have been a disaster had it not been for some stellar QA help. But overall, I was able to finish the vast majority of the code in about 6 weeks, and the QAs were able to catch up and feel secure in their approval around 8 weeks. Naturally being nearly a month ahead of schedule made the PM very happy!

So this week we covered the goals of my new design, the general responsibility of the software objects that I used to create the new system, as well as the Request routing hierarchy. Come back next week, when I’ll be discussing the concrete benefits of the new design, as well as some of the draw backs. Thanks as always for your time!

Part 3 – Return of the Designer




Software Development, Work Projects

Licensing Overhaul – A New Challenge




Anyone who knows commercial software knows the dreaded self-mutilation that is software licensing. From the developer point of view, having the application turn off parts of itself always seemed a little silly to me. But from the business standpoint, it is not only necessary but it is of the utmost importance to generate revenue and to protect your product.

Additionally, Licensing is one of those things that touches everything in the application at least at some level. As a result it can be terrible if you get it wrong, and worse when you have to make changes to it.

For my second stint on a legacy code team, this was the exact task they assigned to me. Honestly, when we started I didn’t think there was any way I could get it done in the 10 weeks I had to do it in. To help get you some idea of what I was dealing with, I will start by sharing what I found out about our previous system.

Now to start off, you should know, this code base is in C++. Furthermore, it bears the scares of a transition from C into C++ and from functional programming to Object Oriented Programming. In laymen’s terms that means that this code base is older than I am. A lot older.

To be certain this code has seen some years, but the fact that it has stuck around this long is a testament to its impressive library of functionality. After all, no one keeps code that doesn’t do something useful.

Getting back on point though, the previous manner of managing Licenses reflects the code’s age as well, though perhaps less favorably. In previous generations of this product License were sold per feature area, rather than as a bundle. The result was that many areas of the applications, and especially the central UI area, are thoroughly riddled with checks for multiple of these Feature Licenses.

Admittedly, the LicenseManager object does a good job of executing its apparent job description. The trouble is that since the a particular function might be available in multiple Feature Licenses, it can be difficult to tell, from the back-side of the UI, what the program is trying to protect from the user.

For the work I did on this system, the proliferation of multiple License checks was especially troubling. You see, recently my company had reorganized the Licenses which they sell, resulting in some confusion between the old and new Licenses in the code. For simplicity I will call them License A, License B, License C ( which is really a combination of A and B) and License D.

My product manager wanted to allow the users under License B to see data which had been created in the same project by users under License A. Further he wanted them not to be able to modify this data, or to be able to import or export it. Given the current system and confusion, this was a very tall order!

As I have mentioned above, the previous system required the UI area to make a number of checks for several different Feature Licenses before determining whether a particular function was allowed to the user or not. Naturally, this resulted in several complex logical expressions in an attempt to determine whether or not the user was allowed to take a particular action.

archaeology-clipart-confusionFor example, in order to determine if a user is allowed to load a given data type from the database, the data manager would first query the License Manager for Feature Licenses X, Y, and Z. Then if the user had X or Y, but not Z they would be allowed to proceed to loading. If they have Feature X they loaded a particular subset of the data, and if they have Feature Y they loaded a different one.

Admittedly this is a simple case, but imagine if this kind of check was made in several different areas of the code. The same check written by different developers at different times for slightly different reasons. The natural differences between coding styles would prevent one from simply searching through the code base for all similar checks.

Furthermore, there is no clear place in the code to determine what a particular Feature License would allow or disallow. This is even further compounded when the new Licenses do not directly match up with a set of Features, and under the hood  they are really just re-skinning  some of the bigger Feature Licenses.

But that is enough of my belly-aching! After sifting through the old implementation, and some whiteboard work, I was able to develop a better design. Please check back next week, when I’ll explain how I made it easier to make the license checks, easier to tell what a license allows and doesn’t, and how I was able to avoid replacing the entire licensing system!

Part 2 – The Whiteboard Strikes Back!

Part 3 – Return of the Designer