In todays blogpost we'll talk about (drumroll please) functional programming. Just why though? Great question. While I know that not every information security specialist or really anybody in infosec has to program something or know a programming language it sure comes handy to know why some people prefer some languages, paradigms and the like. So today we're going to take a quick dive into why functional programming is a thing and why it plays an important role in information security. Roll the tape!
First off, why does this need to be a post?
There are multiple reasons as to why I wanted to write about functional programming, but the main reasons are that people I'm (digitally) surrounded with kept asking me if there's any real need for functional programming.
Second, many people often times don't really care about the programming paradigm they're using as long as the program runs. While I definitely understand that people just want their stuff to run, since it's hard enough to get your program to run in the first place, it's also really important that your code doesn't just run in some scenarios. Some people certainly expect some kind of code quality and rightfully so. That's mainly where functional programming shines.
Third, I just want you to be able to evaluate your own and others code. From my point of view it's basically the same principle that it's beneficial to know about sysadmin stuff, if you wanna do pentesting. In that scenario you know the system better and can exploit it easier, because you somewhat know how it functions. By learning more about functional programming you can tell what the main concerns are, where you'll have to be extra careful and you'll hopefully know when functional programming is useful to you.
With all that out of the way, let me do a...
Functional programming is one of the more well known programming paradigms. It's special in the way that it approaches computation as the evaluation of mathematical functions and it's well known to avoid changing state and mutable data. This also contributes to one of it's main selling points, side effects in functional programming. Usually if you do functional programming you'll have few to no side effects. That's a great thing, since that way we can basically ditch many software bugs, easily fix bugs that exist, test your program and even make it easier to formally verify your program. Isn't that awesome? It basically sounds like a dream for every programmer. But before you get too excited or lost in your thoughts, let's talk about...
So far functional programming sounds awesome, doesn't it? Sure it's great, but some of you might have some misconceptions of functional programming, let's talk about it.
First off, what I described in the introduction part isn't false, but it might be misleading to some. Mostly because almost no programming language strictly, or only enforces the functional programming paradigm. There sure are many languages that implement neat features from the functional programming paradigm, but they also might contain some features of the object oriented, or imperative programming paradigm. This makes the programs "impure" if you happen to use different features from different programming paradigms. Maybe that sounds obvious to you, but I still wanted to put this out so people don't assume something that's wrong.
Second, you already know that with functional programming you try to avoid changing state and mutable data, but there are many other things you'll have to consider and mostly leave out, if not completely leave out. So functional programming can be quite inconvenient at times for some people or absolutely frustrating. This is why I wanna add, that functional programming is perhaps not for everyone and in my opinion not meant to be used in every situation. Though, of course there are very fitting.
So after all this, who actually uses functional programming? Simply put, mostly banks, the military and generally people that develop high assurance software. If you think about if for a moment, it's gonna make sense. As I said earlier, functional programming is fantastic for developing software that generally has less bugs and only few side effects. Banks, the military and other critical software users/developers simply can't afford bugs which might cause downtime, a fatal or even a small error. Just imagine in what trouble a bank would be, if their system would accidentally process wrong transactions for example. Imagine if a Jet would fall out of the sky because of a bug that simply wasn't detected or something similar. This would be fatal.
So this is mostly the use case for functional programming, but it doesn't end here. You remember me talking about formal verification, yes? Formal verification simply put is a verification, that your code under certain conditions is proven to be correct. If you do that, you'll first have to write a specification though and if the specification is faulty, obviously your code will be too. So formal verification can be a very exhausting and lengthy process, but people already have done great stuff with it.
Funnily enough it's not a new concept and back then many people dreamt of entire formally verified systems. This of course seems absolutely insane, but luckily it's becoming sort of a new trend. There are projects like Project Everest from Microsoft for example, which sets it's goal to try and build, as well as deploy a verified HTTPS stack. Also there's this formally verified microkernel, which I'm not gonna name in this post because of trademark reasons. Something I find very interesting as well, is this formally verified WASM module (warning, PDF) which ensures a secure way of using cryptography in webapps like LastPass, WhatsAppWeb and even Skype.
With all that being said
I hope you got a better understanding of functional programming, its use cases and what to do with it. Perhaps I'm gonna make more posts about functional programming and everything affiliated with it in the future. Hope you had fun reading, till next time.