Episode 128: Post Quantum Cryptography

Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy, reliability, and compliance on the Microsoft Cloud Platform. So, hello and welcome to episode 128 of the Azure Security Podcast. I have demoted Michael to being a guest this week so we could ask him some questions. And we're also joined by Jack Richens.

And we will be talking about one of my favorite geek out topics, which is post -quantum cryptography. So we will be skipping the news today and going straight to the discussion. Michael, let's start off. You are now focused on post -quantum computing.

Can you talk a little bit about your new job? Yeah, so probably about three or four weeks ago, I moved over to the post -Quantum team. As anyone who's listened to the podcast for a while will remember, I worked in the Microsoft Red team. Our role was focused in the Red team, was essentially acting as a nation state threat actor, but obviously the good guys.

Learned a heck of a lot. I mean, you know, I always thought I knew about sort of Red team and sort of malware and penetration tradecraft. It turns out I didn't. But I learned a heck of a lot in the meantime.

Unbelievably talented team. Craig Nelson runs a great ship over there. And also it just gave me a really good understanding of the threat intel landscape. Because even though it's the red team and we're sort of acting as...

The team was acting as a threat actor, like a nation state threat actor. I also got to rub shoulders a lot with the people who are actually dealing with the real threat actors out there in the wild, wild web. But yeah, as of four -ish weeks ago, I moved into the post -quantum cryptography team. Again, anyone who's listened to this podcast knows I'm a real crypto wonk.

I love cryptography. I love all aspects of cryptography. Back in the very earliest days of the SDL, the security development lifecycle, I actually owned the crypto requirements. back in the earliest of earliest days.

And then real cryptographers took over. So I'm really happy to be in the post -quantum team with Jack and many others. And so, yeah, by the way, I just want to point something out. This is one of the really cool things about Microsoft.

And I tell this to anyone who's looking at joining Microsoft is get your foot in the door. That's the most important thing. And then you can start moving around, right? So, you know, I obviously started many, many years ago, but I've sort of moved around the company working on different aspects of security and learned a lot along the way.

So my advice to anybody, get your foot in the door and then you can start moving around as you need to. And this is an example of that. You know, Red Team is not post -quantum crypto. Very, very different.

Still cybersecurity, but very, very different. Awesome. And Jack, can you introduce yourself, give a little bit about your background, what you do? Yeah, Jack Richens.

I am the lead for the post -quantum transition team. But my other hat is I manage the Azure security key management team. So this is Azure Key Vault, managed HSM, cloud HSM, a bunch of products with HSM in their names. I've been around at Microsoft a long time in identity, a long time in SQL.

Actually, Michael and I just kind of missed each other, I think, in SQL, but we both worked with a lot of the same people. I am also not a cryptographer in the sense that I implement crypto, but with key management, we turn it into a product. We take the modules that other people... make and then convert that into a product that people can use.

And I think that's valuable in the PQC transition because as we get into it, the algorithms are figured out. It's really about how do we adopt them and roll them out. And that's something we do a lot of in our team. Awesome.

Welcome to the podcast. Thank you. So let's start with, imagine that I know nothing or very little or only the basics of crypto. What is PQC?

What is post -quantum cryptography? Behind it is you need to back up and understand crypto today. We use a ton of asymmetric cryptography. This is where you have a private and public key pair and they're related to each other, but you can safely expose the public key and no one can figure out what the private key is, at least not in the lifespan of the universe with traditional computers.

And these asymmetric algorithms have names like elliptic curve or RSA, but they're using these public private key pairs. What's behind PQC is the algorithms we've been using. Some mathematicians proved that they could actually calculate the private key given the public key using a quantum computer. And quantum computers over the last several years, if you've been following the news, they're becoming more and more real.

And people are actually implementing these algorithms. And it is now becoming very near term that we'll have a quantum computer that can literally calculate the private key. using a public key, using these traditional algorithms. And a post -quantum cryptography is a new algorithm.

In most cases, AES is maybe a special case there, but usually it's a new algorithm or a set of algorithms that there's no known way to break them using a quantum computer. So NIST and the whole industry has been working on this for years and we have algorithms defined and now we're at the stage of it's time to go adopt them because quantum computers are really close. We've finalized these algorithms. We have high confidence in them.

And now we have PQC algorithms that we can go and adopt. So you could say that is PQC. There's a simpler one if you want to make it really simple. I would point at CNSA 2 .

0. That's a set of algorithms and cipher suites that NIST and NSA have worked together on and said, these are the ones that we do not believe a quantum computer can break and go do this. And so then that makes it very concrete. You don't have to understand the math.

You want to know what PQC is, it's CNSA 2 .0 or your equivalent regulation in other countries. Gotcha. So essentially, crypto is all based on one -way math, right?

You can go one way, but can't go back. asymmetric crypto asymmetric crypto yep and then you know essentially what we found is a quantum computer is going to turn that into two -way when they weren't supposed to be two -way and then correct that pretty much uh shakes the foundations of all security on the internet yeah okay cool just making sure i had the i had the net on that one um michael anything i well it's anything right it's not just it's not just like communications it's even things like crypto Like money.

Oh, yeah, yeah. Or stored value, right? I mean, they all use asymmetric algorithms as well. So I really want to stress something here.

And we will talk about algorithms a little bit later on. But to Jack's point, it is the asymmetric cryptographic algorithms that are at risk. And the real problem, what it really boils down to, is that you use asymmetric crypto, as Jack sort of mentioned, to wrap a symmetric key, like AES. Those keys, the AES keys, are, for the most part, There is a little nuance to it, but just humor me.

For the most part, they're okay. But it's the asymmetric keys that become real problems. And the big ones by far are RSA, even though RSA has sort of fallen out of favor because of elliptic curve use in TLS 1 .3, for example.

But elliptic curve is also at risk. And if you look at the math problems, to your point, Mark, RSA is all about factoring large numbers. And for elliptic curve, it's all about this discrete logarithm problem. It's very easy to go forward.

With RSA, you can take two numbers and multiply them together and get a result. But if I give you a 700 -digit number, what are the factors? That's a very, very hard problem to solve unless you're a quantum computer. And some people have asked, what is it that makes quantum computers magic?

They're not magic, but the analogy I like to use, and it's a terrible analogy, but it's pretty good, is if you got on a classic computer today, eight bits right so that can that that eight bits can hold between zero and 255 but it can only hold one number it's either like 127 or three or something right it's not all of them but in a qubit a quantum bit it can actually store all the values at the same time and that's called quantum superposition now i don't want to get into a whole quantum mechanics discussion because then we'll be totally go off the rails, but that's the thing that makes quantum computers so interesting is you've got this, you know, the ability to store all the same values at the same time.

So it's sort of like, it's sort of like a multiverse. If you're looking, if you're like a fan of sci -fi or, you know, Marvel universe or whatever, it's, it's multiple things all happening at once. Correct. Yeah.

Yeah. And then you observe the qubit and it collapses and blah, blah, blah, blah, blah. Right. Or quantum mumbo jumbo comes into play.

But what's interesting is that there's lots of advances on both quantum computing itself and the other one is algorithms to defeat RSA. And the most well -known one is Shor's algorithm, which came out in the mid -90s, and that's spelled S -H -O -R. I won't provide a link to the research, but there's more to it than that. There's been a lot of research since Shor.

that speed things up. So the problem we've got now is we've got constant computers becoming more and more real, and the algorithms becoming better and better and better. And in the middle, they're going to meet in the middle. And we believe that meet in the middle is very close.

Yeah, so let's dive into that timing thing. So how urgent is this? And what is the timing of this is when it's going to become a real security problem? And when should I be starting to think about doing something about it or doing something?

I think there's growing consensus, and you can look at some public announcements from some of our competitors, Google and others, but I think there's growing consensus that it could happen in 2030, that we could have a cryptographically relevant quantum computer. And the other term that's used is a Q date, is the date that a quantum computer can exist that breaks crypto. So that's a date, but it's more nuanced than that. So that's the date when the quantum computer exists.

But what a lot of people don't have to face the reality of is a lot of our communications, our transactions, our data has to be resilient against crypto attacks for more than just this instant moment. There's this attack called harvest now, decrypt later, where people could just harvest network traffic. or capture stolen encrypted data, and it would still have high value years later. NIST and NSA, they've made statements around a lot of government data needs to be protected for 10 to 15 years.

So they're already today in that harvest now decrypt later window for quantum computers, where if an attacker grabs the data today, it's likely still valuable in three or four years until a quantum computer shows up because we're within that 10 to 15 year window. So as we dig into the details, some of the crypto needs to change now. It should have changed yesterday, but yesterday's passed. So we've got to do it now.

And there's some other stuff that can wait until 2030. But as you start digging into the details and the size of the problem and where we use it. Even for those things that can afford to wait for the transition to complete until 2030, you probably need to start doing stuff on that now as well. Well, there's a thing called Mosca's theorem, right?

Which is basically if the migration time plus the sensitivity of the data shelf life exceeds queue day, as you put it, then you're already exposed. Because that means the data is still valid or still should remain sensitive. after Q Day, you know, to your point, like military information, what about trade secrets? You know, imagine you're your favorite, you know, company that creates your favorite soda and they've got, they protected their recipes with trade secrets and they're using classical key wrapping today could be broken and, you know, post Q Day.

Or privacy data and fines around that, right? The EU's not going to care that it was taken four years ago. They'll care that EU citizen data was exposed. Yeah, so it's essentially the attackers essentially grab a copy of the lockbox, and then they have a couple years to pick it, and it's still valuable when they crack open that lockbox.

Right, right. So, clear message, start now. The next question is, what do I start? Yeah.

I mean, Jack just answered that. Yeah. Well, I want to revisit because the space is so huge. It can be overwhelming.

And I tend to bucketize it into data in transit, data at rest. Cryptographic trust is the term I use. There's maybe not a standard of a term in the industry for that third bucket. But in transit, I think should be obvious to everyone that any network communications are at risk of being copied out.

And so in my mind, that's the top risk. And there we can break it down even more. When we talk about data in transit, there's two parts to TLS. There's the encryption.

that keeps the data confidential. And then there's authentication that says, I know who you are and you know who I am. And I know this message came from you. The part that's at risk for HarvestNow decrypt later is the encryption in transit.

And as Michael mentioned, the actual data encryption is already done using AES. That's the good news. So if you're on TLS 1 .3.

Good job. You got that part. But to exchange the symmetric keys, they have to do this key establishment dance. Right now, that's using elliptic curve.

And that needs to move to MLChem as the PQ algorithm for key establishment in CNSA 2 .0. So in my mind, that's the top most urgent risk. At rest.

is also risky, although usually at rest is somewhat defense in depth, depending on your environment and applications. And so there may be other mitigating controls that you can still rely on, even if the crypto is broken. So I put it like a click stop below in transit. And then the last one, the cryptographic trust.

Technically, I don't think there's an attack that you can leverage until Q date. The problem is, as we start unwinding cryptographic trusts, those are the components that are long -lived. To Michael's point earlier, it takes a long time to transition them. So the attack won't happen for a while, but the transition is lengthy, and there's a lot of work there.

Yeah, I don't have a lot to add to that, but I do agree the in -transit aspect is by far the most risky in terms of the threat today. If you're talking between point A and point B, you don't know who's listening. You've got no clue whatsoever. And then when you've got data at rest, as you point out, you've probably got other defenses as well.

Access control, authorization, authentication, and lots of other controls as well. So yeah, the big one by far is in transit. And the cryptographic trust one is really interesting because it's, to your point, not only is it potentially long -lived things, like for example digital signatures on binaries, Some of those roots of trust may actually be in hardware. And now you've got a hardware issue where you've got to start having some of these post -quantum algorithms in hardware, or software on the hardware, or something.

But at the end of the day, it ends up being a real important root of trust as well. The way I've been thinking about this, from the, what do I tell my technology team, or what do I do as a technology professional or security professional? I mean, this strikes me as being extremely similar to a software update and patching process because at the end of the day, the algorithms are just little bits of software that are implemented, right? And so I just have to update all the things that use TLS and all the things that are doing encryption, etc.

I mean, is that the right perspective or is that too narrow or naive? I think that's the right place to start. For the majority of... scenarios, that's where you start.

And certainly it addresses TLS. It does get more complicated. I view it as there's like a long tail of complexity here in custom applications and custom crypto, and that kind of transitions into crypto agility. As cryptography is spread through everything we do in computing, there are examples where they did it in a very crypto -agile manner, like TLS, where there's a standard protocol, there's negotiation between the client and server, and you push out configs.

So to your point with TLS... If you go update to the latest version of your operating systems and your network stack, it probably already supports TLS 1 .3 without you having to do anything. And as PQ algorithms roll out like MLChem, they'll just be added to the Cypher suite.

And so you can treat it just like a vulnerability patching, right? Just update, deploy, you're done. The long tail gets messy. And that's where we start having to do inventory.

And then there's stuff that's kind of in between, like PKI, CA routes. I've lived through a couple of CA route rotations, and they're surprisingly complex to navigate for an organization. And it takes a lot of work. And I think we're effectively going to have to see most routes rotate over the next couple of years.

Sir, there is a real fly in the ointment there. And that is the signature sizes and the resulting ciphertext sizes. Oh, yeah. Who wants to say the bad news?

Me or you, Jack? You can say it. Oh, thank you. The size of the resulting signatures or ciphertext, whatever, is huge.

Or the key wrapping blob is huge relative to the size of, say, an AES wrapped with an elliptic curve. Signatures are a lot bigger as well. that's going to cause problems for some people. And for example, the TLS handshake ends up being bigger, substantially bigger.

And there may be performance implications of that. Now, luckily, it only happens once at the beginning when the handshake is done and client hello, server hello, and they finally establish the keying material. But I'm very glad you said TLS keys before not key. It's amazing how many people think there's one key.

There's actually not. There's like, isn't that like eight keys or something that was established between the two for different, for A to B, B to A encryption and a Mac if you're using an HMAC or something like that. There's a couple, an initialization vector, I think. There's a few others as well.

It's not just a key. Anyway, yeah, the key point, no pun intended, is that people need to be aware of the fact that the resulting cipher blob, whether it's a signature or a key wrapping, is significantly larger than what we're used to today. And that might cause problems, especially on some of the downstream hardware. Also, we're seeing issues where some of that data is passed on a query string and some browsers or some intermediate HTTPS stacks don't like it because it's too big.

So the whole industry is going to get a real shakeout. My analogy for this is it's a lot like the Y2K problem. It's coming up whether we like it or not. And a lot of work needs to be done in a lot of places, including identifying where these places are before you can fix them.

But I think the overall potential for regressions is actually quite high relative to smaller changes, even like Y2K, which went off smoothly. But it only went off smoothly because everyone did so much work. So what are your thoughts about that, Jack, with the size of these signatures or the size of the key wrapping blobs? Where do you see issues?

Yeah, well, two things. I'll make it a little bit worse, and then I'm going to share some good news. The worst part is the size. What a lot of people don't realize is it's not merely that there's more data being transmitted, but now it ends up being spread over multiple packets.

And that introduces challenges with packets showing up out of order or getting stuck and taking longer to get to the destination. and breaking a part of the protocol that we're used to going really fast now. We're not in the days of dial -up modems where that negotiation was expected to take multiple seconds. Now everyone's used to that just happening.

And I think there's a very real fear that... Some software is going to break. They're going to have to change some of their timings and become more resilient to deal with these larger sizes. There's also challenges with some of the hardware because some of the, you mentioned code signing, so it's not just TLS, but there's code signing.

There's multiple algorithms there that they can use for signing, but some of them like MLDSA result in really large signatures. They have challenges cramming the algorithm and the signatures into hardware. There's not room for multiple signatures, which is another challenge there. So that's kind of the even worse news.

I think the only thing I would say, because I don't want to scare anyone away from TLS 1 .3, is all of those issues around signing, etc., they primarily implicate... authentication, cryptographic trust, and not the actual data encryption.

And the way TLS 1 .3 breaks up the protocol, those cipher suites can be rolled out independently of the certificates that identify the server. And there's been very good testing in the industry and with Microsoft and with our own stack, TLS 1 .3 with the key exchange that preserves your confidentiality.

that's going well. The software is dealing with that well. We don't see issues there. You shouldn't see perf issues.

So don't be afraid to go roll out what the industry is rolling out now. You can go look at endpoints and you'll see endpoints offering TLS 1 .3 with elliptic curve hybrid with MLChem. So it's doing a double encryption and it performs fine.

And go do that now. Protect your data in transit. Cryptographic trust, those signing operations and the signatures are huge. Yes, that's big and scary and risky, but we have some time to go work through that.

Do you want to talk about the hybrid in a little bit more detail? Because I think that's really important. Yeah. So I guess double encryption is, I wouldn't say it's wrong, but it's an ambiguous term.

And you've done a bunch of research into this as well, Michael. But the high -level concept is, you mentioned there's multiple keys. They literally have two keys to do the key establishment. elliptic curve.

They still use an elliptic curve key and they have an MLChem key. They're different keys and they're encrypting two different symmetric keys that are then going to actually encrypt the data so that in order to break an TLS 1 .3 stream that's been hybrid encrypted in this manner, you have to compromise elliptic curve. and MLChem.

And the reason the industry wants to do this is, while we know quantum computers are coming, that's a probabilistic statement because it's still in the future. And conversely, MLChem and all of these PQ algorithms, while they've been really tested well by NIST, NSA, Academia, cryptographers around the world they're new and cryptographers are a paranoid bunch and they're like yeah all it takes is for someone to come along and approach the problem in a unique way we never thought of and they might find flaws here and so right now the guidance is do some kind of hybrid composite scheme where you have to break both a traditional algorithm that is a known quantity and resilient against traditional computers, and you have to break the quantum -resistant algorithm.

So it's almost like the cryptographic version of a two -person rule or a two -man rule, right? Yeah. Where you can get one, but that doesn't get you both. Right.

And we're forcing you to break both as much as possible. I think with the key sizes and hardware, we're running into situations where that's not possible. But wherever we can do it in software or in other areas, we're trying to implement that two -man rule. And NIST is still doing research, right, on other algorithms.

Because, as you say, the new algorithms, which we will talk about a little bit later on. are new and we don't know what's around the corner right and if all of a sudden something's found out we may need to move on to tls 1 .3 with new algorithms who knows yeah and like you mentioned before like elliptic curve and um and rsa they're both founded on certain one -way math problems like the prime numbers the new crypto algorithms that they introduced and i love to talk about their names that everyone's forgotten the code names already but they're all based off of lattice mathematics and that so that's fun that's neat um and the code names for the original algorithms were Kyber and Dilithium, so it's Star Wars and Star Trek.

And then when they came up with the official names, they kept the first initial. So Dilithium became MLDSA and Kyber became MLKEM for key establishment. key establishment mechanism. So somebody there did their work so they could have the names make sense, but also pay homage to Star Wars and Star Trek.

But they're both based on lattice. And so then the fear is, well, we've really studied it. We don't know how to break this now, but what happens tomorrow? And so they're continuing to research other mathematics that they could use for this.

and algorithms based on those maths also the keys the sizes like they they've heard the feedback from the industry and they're trying to see if there's something they can do to get the sizes down so there continues to be research there so i have a really terrible analogy for lattice um crypto um but you know i i'm fine with terrible analogies as long as it gives you at least a mental model for what the problem is um so imagine if you have a chess board and you have a knight on the chessboard.

If I tell you to move two up, one right, one down, two left, or something, and keep doing that, you can get to a certain point. Now imagine if I give you a chessboard and say, hey, here's a knight on a certain position. How do you get to that point? And you don't know.

It's almost kind of like trial and error. It's like, how do you actually get to that end point? You may think, well, that's really easy on a chessboard. It is.

But imagine... not two dimensions, but imagine 500 dimensions with lines, vectors that are more than two and one. And also you introduce a little bit of error in there as well. That's kind of how lattices work, kind of.

It's very easy to move forward, like in other words, to get to a point and then say, hey, here's my point. But it's very difficult to say, here's my point. How do I get back to this other, this starting point with these nights or these vectors? So that's kind of what the problem is.

And to your point, Jack, we believe it's quantum safe and we believe it's fine, but what happens if someone does some research? Things only get better and faster. What happens if we find out 10 years from now that we were dead wrong? So, yeah.

Yeah. And kind of thinking about it from the practical standpoint, if I'm running a CISO or CIO or someone in a technology or security team that has to kind of figure this out, I think about that crypto agility term, which is I have to expect that maybe algorithm A didn't cut it or Kyber to Lithium didn't cut it and now we have a new version, a V2 or V3 of that or something else entirely. That's part of what it is is you've got to just get on this point where Crypto isn't, hey, we settled it and now we're good for 30 years.

We have to keep updating it just like we do any other software vulnerability. Exactly. And that transitions nicely into the crypto agility discussion we were having earlier. There are well -trod patterns where we have really good crypto agility, like TLS.

quickly say, hey, everyone, just stay up to date on TLS and the cipher suites are going to roll out and you're going to be fine. And it's just patches, just like a vulnerability versus kind of the long tail of cryptography where people have gone out and built their own thing. They have to go rebuild it. And if they continue to do custom crypto, they could go switch it to use MLChem and MLDSA.

And five years from now, they could have to come back and do it again. And in my mind, now is the time to prune that long tail and wherever possible, abandon non -standard protocols, use TLS, abandon custom libraries that are doing your crypto, use standard encryption libraries that are well maintained so that you have somebody doing that. crypto agility work for you and it's turned into a vulnerability patching problem rather than go hire an engineer, do exhaustive research of your code base and rewrite it to support some new algorithm that's just too expensive, too painful.

You'll make mistakes. You'll introduce regressions. We got to cut off that tail and move to standard protocols in crypto. Yeah, it's just like when people were starting to adopt cloud, it's to configure before customize.

If you don't need specific custom crypto implementations, use the standard well -tested stuff. And please, please, please don't roll your own crypto. I mean, sometimes you need to manage your own route. You have certain things.

But if you don't have to handle the plutonium with your bare hands or remember to put the gloves on, try not to. And I think it's that next level of it, because I think that was the mantra when STL was rolling out. Never implement AES. Go use the standard implementation.

And I feel like this experience of the PQ transition is taking that the next level up. Not only should you not implement AES, you should try to use libraries where you don't even have to know AES is being used. You're calling some function that just says encrypt. And it's figuring out the right thing to do.

So I had one last question, because as you were mentioning, we've got larger sets of data being produced, used, calculated, etc., which is going to take more processing, more memory, etc. It feels like there's going to be, as part of that sort of long tail of problems, you've got IoT devices like cameras and crop sensors and all that kind of stuff that... Even if you could update them, they might not have the juice to actually do these kind of operations.

Is that a correct assumption in that there might just be some either isolate them like OT devices or e -waste sort of issues? I'd love to hear your thoughts on that. I have thoughts. I'm not sure I have answers.

I think there is a risk there. I think vendors have gotten better over the years at making their hardware a little bit more upgradable. And I've heard some good news about some components that we've looked into where we didn't think they'd ever be able to update and they are able to update to the PQ algorithm. So it's not as bad as I feared.

I think a second mitigation is, although we talk about the Q date and in abstract terms you can assign a single date to it in more practical terms kind of like the vulnerability there's a cost to it an attack and so there has to be a value for the target right and when we say cute date that's the first date that the you know the most motivated attacker is going to be able to afford to buy a quantum computer and they initially they will not just instantly get answers, it will still be multiple days to break.

So Q date's very real. I don't want to roll back any of my statements earlier about how panicked we should be. But if you think about that, if you have a super expensive quantum computer, it still takes you some reasonable amount of time to crack a key. If you have a choice of targets, you're going to go after CA roots for valuable targets.

And IoT devices are probably, depending on the device, are going to be lower down on the threat landscape. And they may have a little bit more time to transition. That'll be case by case. If it's an IoT device used by the military, throw out everything I just said.

But, you know, if it's like a leak sensor underneath your sink, that's... relatively low value uh both from an adversary's perspective and what they could do with even if they compromise it and wanted to go rogue within my home network it's still a really weak device um it's not even using wi -fi and so um there definitely will need to be some triaging and with that particularly around the cryptographic trust area where You're going to come up with your inventory. You're going to look at all the stuff.

High value assets, you got to transition those first. Some of those, it may turn into a monetary risk decision of this is super valuable. It's super risky. We pay the money, we replace it.

And we've created e -waste for this one scenario. But there may be other scenarios where it's lower risk and you can afford to let it play out a little bit. So you have to know what's valuable, what's important, and especially with that time value. What is the stuff that's going to be valuable over 3, 5, 10, 15, 20 years that still has to stay secret or controlled or what have you?

Yeah, but to Jack's point, the little device monitoring for leaks, I mean, that data's not sensitive. It really isn't. And let's be honest, if it's a small... device out of somewhere.

It's probably been compromised anyway and the attacker's got the keys anyway. I hate to be so cynical. That's your red team job coming back. Yeah, exactly.

And that's why at home here, I mean, all the IoT devices are on their own virtual network. I don't trust them, man. They don't have access to my network. No way.

And that's a great point. Kind of like with the encryption at rest, there can be secondary mitigations that don't rely on crypto or that you could isolate the network so that you have a device that can speak PQ network crypto and it isolates those devices that don't. So I think there will be patterns there. can be leveraged to protect them.

Yeah. And the patterns are going to be very similar to, Hey, we have this old OT device that's stamped steel and it doesn't support crypto at all. So whatever you do for that will probably be very similar for, Hey, this one's easily compromised. Probably the right way to think about it is all of these IOT devices that do traditional crypto, just assume they don't do crypto anymore and treat it that way.

So as we're getting close to wrapping it up, it sounds like the frame of thinking that organizations should have in mind is, hey, we need to start now. We need to think about it like a special version of a software update thing, which sometimes results in isolation because there's no way we can update it. And it's really very heavy on the TLS, right? And then thinking in terms of crypto agility.

So, I mean, is that sort of the right way to think about it? Yeah, I think that's exactly it. I think Michael and I are trying to be better in our communications. We've been telling customers for years about doing a crypto inventory.

And Microsoft has been through that exercise as well. We're kind of coming out of that phase. And so internally, we're not talking about that part as much. But for a lot of organizations just getting started on their journey, they should start with an inventory of what are their most valuable assets and what is the cryptography protecting it and make sure they have a plan there.

And let's be honest. I mean, the crypto inventory for something like Azure is incredibly dynamic. This isn't easy. Yes.

Yeah. I look at keeping an inventory as like keeping a house clean. It's never going to be perfect, but you also don't want to be in a dirty house. So you got to keep doing the work.

Yeah. And with your analogy to vulnerability, it's a lot of it is scanning. Just because it was clean today doesn't mean it'll be clean tomorrow. So we rely heavily on network scanning and other detections that are automated.

So we see things coming in. Right. Cool. So can you talk a little bit about like which algorithms people should be looking for?

Like these are the ones that are good, validated, blessed, and then kind of how's Microsoft approaching it? Yeah. So the algorithms I mentioned earlier, CNSA 2 .0.

Go Google that on the web, pull it up. That's kind of my Bible at the moment. Those are the main algorithms. And you'll see it actually starts off with some familiar faces.

To Michael's point earlier, symmetric crypto more or less is holding. So it's SHA -384, AES -256. You'll notice the links are a little bit longer than some previous standards. So they did make them longer because there are some...

accelerations from quantum computers, but fundamentally they're holding strong. So get a good solid sized key and you can keep using those algorithms there. And then the new ones that you'll see several of them mentioned, my favorite one to talk about because it's like the rock star right now is MLChem. It's being deployed across the internet right now.

And it's protecting that key establishment in TLS. And it seems to be going well. It's not really causing problems. And it's the gold standard right now for PQ key exchange or establishment.

When you get into the signatures. Like Michael was mentioning earlier, there's these size issues and performance issues, and there's a couple of different ones. The MLDSA is kind of MLChem's sibling for digital signatures. There's an older one called LMS that a lot of hardware vendors liked because it was available sooner and they could start rolling it into their hardware devices.

And those are kind of the two signature ones. I don't want to... As far as the signature algorithms, they work fine. LMS has some issues in that only one person can be doing the sign operation at a time.

So that creates some management issues. And MLDSA doesn't have that. behaves on the signing side a lot more like RSA and EC. It doesn't have the restrictions LMS has.

And so we're kind of seeing this trade -off in the industry right now where a lot of hardware and IoT has added support for LMS and all the software people are going to MLDSA and probably will, I don't think they'll ever consider LMS. There's too much management overhead with it. And that is the area that NIST is most aggressively continuing to look for alternate algorithms. Anything to add there, Michael?

Yeah, there is another one, which is SLHDSA, right? So what's the scoop there? The key word in that is stateless hash -based. So do you want to touch on that at all?

Or is that just going to really send us down a rabbit hole? It's another one. I think, yeah, I don't have much to say about it. Some modules are still implementing it.

And as I'm not one of the implementers, I'm not sure why, but ML DSA seems to have been more popular around the implementation. Michael, I know you've been looking at some of this. Is there something you wanted to share about that? No, not really.

I just thought I'd throw it out there just for completeness. You're probably going to hear ML KEM. You're going to hear about the most. Next will be MLDSA, and you may hear some SLHDSA.

The only thing you need to know is that the SLHDSA is a lot slower, and it also has much bigger signatures. My guess is it will be used for things that are going to be extremely long -lived. you know, 30 years sort of timeframe. Yeah, exactly.

Exactly. But, you know, who knows? Anyway, I just wanted to just throw out, because people are going to see these things. Yep.

And it's worthwhile. We'll see LMS for hardware devices. Okay. I don't mean to badmouth it.

Like it is NIST approved. It's a solid algorithm. The challenges there are on doing the signatures. But if you're buying.

a component like a TPM or a CPU that uses LMS. It's the manufacturer that had to deal with that, so you don't care. And you can benefit. It is a NIST -approved algorithm and should be fine.

And you bring up a really interesting point there, though, and I really do not want to go down this rabbit hole, but I'm going to circle around the top of the rabbit hole, and that is standards. A lot of the standards are still evolving in this area. That's all I'm going to say about that. Yes, a huge rabbit hole.

They're still evolving. And that's why it's easy to point to TLS. It's the top risk and the standards are relatively solidified and being rolled out. So go do that.

It's the top risk. It is standardized. As you start, look, and at rest mostly uses AES. So you're good there.

The cryptographic trust, the standards. aren't completely finalized. And so you're kind of at the stage of get your inventory, talk to your vendors, talk to the teams that you rely on, your HSM vendors, your PKI providers or teams inside your company and start figuring out your plan. But know that for cryptographic trust, several of those standards are still being finalized.

So they may not be ready to go do something this quarter. But people are moving fast now. They see that date coming. It's become a lot more real and things are moving fast.

So I got one last kind of technical question before we get into our kind of standard wrap up. What is Microsoft doing that folks should be aware of in this space? Yeah. So we started our inventory a long time ago and identified a lot of our foundational components.

And if you've been following the news, it's kind of buried because it's kind of crypto stuff. But our cryptography team that actually implements crypto for Windows and Linux and other products, they've been delivering their crypto module, SimCrypt, adding these new algorithms. at a really regular cadence. So they're all out there and they're continuously making new announcements.

They're very much up to speed. So that's been a big investment. And what you're going to start seeing coming out next is, well, we already support TLS 1 .3.

That's been out there for a long time, but we'll start integrating these algorithms into our products and you'll see those coming out very quickly here. And that's kind of a sign we're transitioning from the inventory and solve your kind of core component issues to deploying and rolling it out so that we're using it internally and customers can adopt it. And that's what we'll be busy doing over the next couple of years, trying to give our customers enough time so they can go through that transition themselves.

Because almost all of this, there's... So it's not exactly client -server, but there's kind of producer -consumer model, right? We have to make it available. Our endpoints have to support it.

Our clients need to support it. And then the customers can go rotate their routes, rotate their keys, and adopt it. Yeah, and just to add to that, so it really is very much a layered approach, right? So we've got SimCrypt essentially down the bottom, which is the actual low -level algorithms.

By the way, that code is up on GitHub if anyone wants to look at it. the post -quantum algorithms into .NET, and they just call out to SimCrypt so you can do it nice and easily in .NET.

Then the next layer kind of above that would be the likes of TLS, which would then also consume SimCrypt to provide the asymmetric, sorry, the post -quantum algorithms in TLS 1 .3. We will have a version of S -Channel, so in Windows, the code that does that is called S -Channel, and we will have that out very soon with post -quantum algorithms. built -in as well, so you can go and kick the tires on it.

And then you'll see other products with data at rest and so on, but the big one by far is TLS 1 .3 with post -quantum algorithms. I'm going to wrap it up with two questions. The first is for both of y 'all.

What's a day in the life? So Jack, if you can kind of give us a sense of what is life like in the midst of this command center? Well, I start every day with a good workout before I open up my phone and start looking at the day's fire drills. So I get my workout in, say my prayers, and then open up email and chat.

A lot of my days, because I'm still running the key management team, so a lot of my day is split between on the post -quantum side, meeting with the experts and teams around Microsoft. Bringing them up to speed on what I'm seeing, learning from them about the challenges they're seeing and working to find solutions. And a big part of that is we're leveraging. We're now kind of transitioning from building components to rolling it out.

And so we're kind of transforming all of these crypto transitions, kind of like long patching into KPIs that we can just go drive from zero to 100 percent. And, you know. Forming those KPIs, getting teams to own them, and helping people, the DCSOs, properly understand the risk for each of these KPIs. Because they are different, as we discussed, for TLS versus encryption at rest and cryptographic trust and getting the appropriate level of urgency.

Because for the consuming teams, they have to consume this work alongside existing vulnerabilities, existing security issues. We want to make sure the risk is appropriately understood and not oversold because we don't want them wasting effort if there's something else more urgent. So it's a lot of those discussions, writing, working with Michael, trying to get communications for internal and external consumption on what people need to go and do. And then all the fun stuff I get to do around key management with HSMs.

cloud computing there and sovereignty. We've been talking about external key management. That's a fun new feature. We could talk about that sometime too.

So just going back and forth between the two and trying to stay happy and positive and get home to my family at the end of the day. I tend to actually do my workouts in the middle of the day around lunchtime. I wish I could do them in the morning. My wife wants me to do them in the morning, but that's another discussion for another day.

So my day starts, actually a bit of a joke really, is I make coffee for both my wife and I. And it's actually kind of a bit of a laugh because if I'm not around and she has to make her own coffee, she complains about it. And it makes me aware, you know, rubs it in for the rest of it. I had to make my own coffee this morning.

And a big one I do because I'm two hours ahead of Redmond. There's sometimes there's stuff that's coming overnight. Earlier this week, and I really am telling tales outside of the playground here, Jack, but there was a message earlier this week from Jack saying, hey, when you wake up tomorrow, you need to work on this one thing, which I did. But yeah, a big part of what I'm looking at is, so the buzzword right now inside Microsoft is reducing toil.

A lot of security stuff is just hard. It's just a lot of... toil. It's stuff that you've just got to do because it's the right thing to do.

So we are working out how can we come up with appropriate guidance, really prescriptive guidance, but also using AI to help make the impedance a lot lower, sort of reducing that resistance. And so a lot of work I'm doing in that area with the crypto board at Microsoft. I think that's really important. In fact, I think if anyone is not doing that, they really should be doing it.

Something else I left out is for me to bring it up. Jack, I said a little prayer over my wife every morning. Yeah. And then a lot of it is, is email and correspondence and talking to product groups, but also talking to customers.

A lot of customers, this sounds like a horrible thing. I don't mean it, but just have no idea what to do. I don't mean it in a horrible way. And they're really looking to us for guidance and help.

And so a big part of what I'm doing is not just working with our first party customers, like, you know, storage, Azure data. I'm spending a lot of time now with the Azure data team, in part because I think they have a reasonable story moving forward, but there's some areas that need real work. And then also working with customers as well. A lot of them seem to have come from finance and governments.

It seems to be a common pattern. So no day is the same, ever. I still get a couple of pings from the red team once in a while, but that'll end up stopping at some point. Every day is totally different.

So, Jack, final thoughts. Anything you'd like to leave our audience with as sort of the most important thing to sort of remember and take away? I think I've definitely seen what Michael just mentioned there about the feeling of overwhelmed. And I think some of the analogies you shared and just kind of breaking down the problem into segments like your network communications and TLS and others, I think are super helpful.

People pretty quickly get the urgency and then they quickly get overwhelmed because they start looking around and they realize we use crypto everywhere throughout all of our products, everything we're doing. And that can be overwhelming. And it's just kind of pause, take a breath, break it down, look at TLS. Your encryption at rest is probably already.

fine, just double check. And then once you do that, you're like two thirds of the way through the problem. And so then in that last area, it's yeah, start getting the inventory, but the standards are still coming. So, so just be ready.

And it's. I think we can do this much like Y2K. Hopefully, you know, five years from now, we're sitting the other side of the transition and quantum computers are here and we're looking back and like, yeah, it could have been really bad, but the industry rallied together, just worked the problem and we got out the other side and it's okay. So thank you so much for joining us.

And Michael, thank you for being a guest on the podcast you started with us. And with that, we're going to wrap up. And thank you all for listening. And we will catch you next time.

Stay safe out there. Background music is from ccmixter .com and licensed under the Creative Commons License.