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.