If you work in either the audiovisual (AV) or information technology (IT) sectors of our economy — you’ve probably heard the term ‘AV/IT convergence.’ It’s a term that gets overused and unless you’ve been installing cables on Mars, you’re probably as tired of hearing about it as I am. What AV/IT convergence really means, in short, is that most of AV is being re-thought in terms of software. Systems that once required complex and custom hardware can be re-envisioned as software or even cloud-based services. Cool. But you’ll notice that the convergence is mostly one-directional — AV systems aren’t replacing software. This means AV professionals must adapt to a software-based world. This can be a valuable to both you and your customers.

I’ve written about software and IT basics here before and several readers have asked me to continue the theme. In this post, I’ll focus on encryption. Why does this matter? Because it REALLY matters to your customers (read on).

From an AV perspective, encryption became important when digital rights management (DRM) found a home in the hardware of the HDMI cable. But encryption is beginning to go well beyond DRM. As video is managed, routed, and displayed via software systems (i.e., Solstice) — it’s important to keep that data protected as it moves through the enterprise network. Encryption also has all the hallmarks of a great cocktail party topic — it’s relevant to the modern world that struggles with privacy and security and it’s based on some very cool math. Sexy.

How does encryption work?

The goal of encryption is to exchange information between two endpoints: in this example, two kids in history class, by agreeing upon an algorithm that will transform plain text into encrypted content that can’t be read by a third party, the teacher. The two kids may decide that they will simply replace every character in the alphabet by two letters to the right, so instead of ‘C’ write ‘E’ in its place. This algorithm is known as the cipher. This cipher can be written mathematically as: e = (O(p)+2) modulo 26, where O is the ordinal value of the plaintext character and the modulo operator takes the remainder of our shifted value divided by 26 — this handles the fact that there are only 26 letters so we need to “wrap” back to one when appropriate. When a note is passed in class, it can be decoded by anyone who knows the cipher simply by implementing the inverse of the cipher; take each letter and replace it by the character two letters to the left in the alphabet.

This is a very simplistic cipher, but by understanding what’s wrong with a cipher like this we’ll gain some real insight into how modern ciphers operate and why. First off, it’s susceptible to ‘brute force’ attacks. An example of this would be if a determined individual replaced characters with various offsets until a valid message was discovered. While it may be tedious for an individual, it wouldn’t take much for a computer to automatically attempt all types of offsets, replacements, etc. Furthermore, for ciphers of this type, you may not need to try all combinations, because by consistently replacing characters you haven’t changed the statistical properties of messages. Using letter frequency, I could limit my guesses to ones that are more likely — if you’ve ever seen The Imitation Game, this realization led to dramatic flair and a solution to the German Enigma cipher.

This type of cipher is also very problematic because once you ‘crack the code,’ all messages can now be decoded. If our imaginary teacher intercepts one note, she/he can spend lots of time determining the cipher. Once the teacher knows the cipher, they can simply implement the inverse algorithm and read all messages. This is because the algorithm is the only thing you need to know to transform encrypted text to plain text.

Enter modern encryption algorithms. Most algorithms used to encode data these days are based on a couple of principles. The algorithm used to encode the data requires an additional piece of information that is never shared — this is called the ‘private’ key. Even if a message is intercepted and somehow decoded, the teacher threatens extra math homework until the sender describes the algorithm for example, but new messages still cannot be decoded without this private key.

This type of cipher is then weak to ‘man-in-the-middle’ attacks. This means that if individuals intercept the message, they can learn about your cipher enough to decrypt it over time. Man-in-the-middle attacks are particularly important in the modern world, where information is often routed through unknown servers.

The cipher algorithm relies on mathematical functions that are very difficult to invert. In the example above, the complexity of encoding the message exactly matches the complexity of decoding — by replacing a character with one defined by the algorithm or its inverse. So, here’s where things get interesting.

How do I agree upon an algorithm then, without allowing that algorithm to be the key that unlocks all messages?

I want to retain the ability to decrypt messages with my private key, but still want others to be able to send me encrypted messages — this is accomplished by exchanging what is called the ‘public’ key for others to use. This public key is a derivative of my private key so that when I apply my decode algorithm using the private key — I get a plaintext message. Hmm… You might wonder ‘If the public key is derived from the private key, can’t I figure out the private key (and the algorithm) in the same way?’ The answer is ‘practically’ no.

The crux is selecting a mathematical relationship between the private and public key that allows me to compute a public key easily from my private one, but is nearly impossible to compute the private key given to the public. It just so happens that such an operation exists — and we all were exposed to it in about fourth grade: factorization of numbers.

Imagine that I decide my private key is 443 (a prime number). I’ll give out a public key that is my private key multiplied by another prime number, 461. This is a VERY easy operation to implement and you can tap 443*461 into any calculator to derive 204,223. For you to derive my secret private key from the public key, you need to somehow determine the two prime factors that make up the key. In other words, you would have to perform prime factorization on 204,223. This is much harder operation than the forward operation of multiplying two numbers. In fact, the exact complexity class of prime factorization is still unknown but the difficulty of computing the prime factors of an N-digit number grows more than linearly with N. This means, as you pick longer and longer numbers for your public key, the complexity grows well past what a modern computer can handle. As an example — a group of researchers in 2009 attempted to factorize 232-digit number using hundreds of computers and found that it took two years (the original paper is an interesting read and can be found HERE).

The modern RSA encryption algorithm (named after the inventors Rivest, Adleman and Shamir) is based on nearly the same algorithm I just described; however, the public key involves not only the multiplication of two numbers but also a second number based on modulus arithmetic. While it’s out of scope to describe the RAS algorithm here, the principles are the same. Keep in mind that with a 1024-bit RSA key, the same study in 2009 determined that factorization would take about 2,000 years.

OK, so we’ve shown that there is a secure method that can link a public and private key pair in a way that makes it practically impossible to guess my private key — even if you have the public. All that remains would be to develop an algorithmic cipher that encodes messages using the public key and decodes them using the private. You’ll notice that this means the encoding algorithm is different than the decoding algorithm. This is what people mean when they say asymmetric ciphers. This asymmetry is important because even if you know the algorithm, you still can’t decode a message unless you know the private key and we know that it could take thousands of years to derive the key.

But why can’t I simply try all prime numbers smaller than the public key, run it through the decrypt algorithm and see what happens?

I won’t go into the actual details of the encryption/decryption algorithms in use — but it suffices to know that brute force guesses of private keys are nearly impossible because the number of possible private keys for a large public key is absolutely huge. For example, assume a public key that is 1024 bits long, the number of 512 bit primes is about 2.7×10^151, that’s a 2.7 with 151 zeros!

OK, so we have learned about asymmetric encryption, brute force attacks, man-in-the-middle and the mathematical reasons behind why all this works. Why does this matter to the AV industry?

As AV migrates to software/IP networks, you’ll find that network security and IT teams at your customer’s site will play an increasing role in deploying AV gear. They are going to want to know the security impact of an AV product on their network and they’re going to want details on how that product protects their video data. When an IT executive asks, “What cipher does that wireless video product use?” or “What’s its encryption key length?”, you should be able to lean into the conversation, gain credibility and help your customer. These conversations are the real manifestation of AV/IT convergence and you’ll be leading the charge. How cool is that?

This column was reprinted with permission from Mersive and originally appeared here.