WEBVTT

00:00:03.660 --> 00:00:06.240
Welcome to the Azure Security Podcast, where

00:00:06.240 --> 00:00:08.759
we discuss topics relating to security, privacy,

00:00:09.039 --> 00:00:11.460
reliability, and compliance on the Microsoft

00:00:11.460 --> 00:00:16.739
Cloud Platform. So, hello and welcome to episode

00:00:16.739 --> 00:00:20.820
128 of the Azure Security Podcast. I have demoted

00:00:20.820 --> 00:00:23.379
Michael to being a guest this week so we could

00:00:23.379 --> 00:00:26.539
ask him some questions. And we're also joined

00:00:26.539 --> 00:00:29.320
by Jack Richens. And we will be talking about

00:00:29.320 --> 00:00:32.420
one of my favorite geek out topics, which is

00:00:32.420 --> 00:00:35.479
post -quantum cryptography. So we will be skipping

00:00:35.479 --> 00:00:38.600
the news today and going straight to the discussion.

00:00:39.130 --> 00:00:41.789
Michael, let's start off. You are now focused

00:00:41.789 --> 00:00:43.469
on post -quantum computing. Can you talk a little

00:00:43.469 --> 00:00:45.789
bit about your new job? Yeah, so probably about

00:00:45.789 --> 00:00:47.509
three or four weeks ago, I moved over to the

00:00:47.509 --> 00:00:49.469
post -Quantum team. As anyone who's listened

00:00:49.469 --> 00:00:51.670
to the podcast for a while will remember, I worked

00:00:51.670 --> 00:00:54.609
in the Microsoft Red team. Our role was focused

00:00:54.609 --> 00:00:57.710
in the Red team, was essentially acting as a

00:00:57.710 --> 00:01:00.310
nation state threat actor, but obviously the

00:01:00.310 --> 00:01:02.969
good guys. Learned a heck of a lot. I mean, you

00:01:02.969 --> 00:01:04.909
know, I always thought I knew about sort of Red

00:01:04.909 --> 00:01:08.530
team and sort of malware and penetration tradecraft.

00:01:08.629 --> 00:01:11.439
It turns out I didn't. But I learned a heck of

00:01:11.439 --> 00:01:13.900
a lot in the meantime. Unbelievably talented

00:01:13.900 --> 00:01:16.819
team. Craig Nelson runs a great ship over there.

00:01:16.980 --> 00:01:19.099
And also it just gave me a really good understanding

00:01:19.099 --> 00:01:21.760
of the threat intel landscape. Because even though

00:01:21.760 --> 00:01:23.500
it's the red team and we're sort of acting as...

00:01:23.689 --> 00:01:26.409
The team was acting as a threat actor, like a

00:01:26.409 --> 00:01:28.810
nation state threat actor. I also got to rub

00:01:28.810 --> 00:01:30.030
shoulders a lot with the people who are actually

00:01:30.030 --> 00:01:32.409
dealing with the real threat actors out there

00:01:32.409 --> 00:01:35.890
in the wild, wild web. But yeah, as of four -ish

00:01:35.890 --> 00:01:39.310
weeks ago, I moved into the post -quantum cryptography

00:01:39.310 --> 00:01:41.569
team. Again, anyone who's listened to this podcast

00:01:41.569 --> 00:01:44.090
knows I'm a real crypto wonk. I love cryptography.

00:01:44.109 --> 00:01:46.689
I love all aspects of cryptography. Back in the

00:01:46.689 --> 00:01:48.950
very earliest days of the SDL, the security development

00:01:48.950 --> 00:01:51.370
lifecycle, I actually owned the crypto requirements.

00:01:52.010 --> 00:01:53.769
back in the earliest of earliest days. And then

00:01:53.769 --> 00:01:56.750
real cryptographers took over. So I'm really

00:01:56.750 --> 00:02:00.250
happy to be in the post -quantum team with Jack

00:02:00.250 --> 00:02:03.769
and many others. And so, yeah, by the way, I

00:02:03.769 --> 00:02:04.870
just want to point something out. This is one

00:02:04.870 --> 00:02:07.000
of the really cool things about Microsoft. And

00:02:07.000 --> 00:02:09.500
I tell this to anyone who's looking at joining

00:02:09.500 --> 00:02:11.740
Microsoft is get your foot in the door. That's

00:02:11.740 --> 00:02:13.979
the most important thing. And then you can start

00:02:13.979 --> 00:02:16.939
moving around, right? So, you know, I obviously

00:02:16.939 --> 00:02:19.280
started many, many years ago, but I've sort of

00:02:19.280 --> 00:02:22.080
moved around the company working on different

00:02:22.080 --> 00:02:25.300
aspects of security and learned a lot along the

00:02:25.300 --> 00:02:27.379
way. So my advice to anybody, get your foot in

00:02:27.379 --> 00:02:28.740
the door and then you can start moving around

00:02:28.740 --> 00:02:31.340
as you need to. And this is an example of that.

00:02:31.500 --> 00:02:33.500
You know, Red Team is not post -quantum crypto.

00:02:33.659 --> 00:02:35.599
Very, very different. Still cybersecurity, but

00:02:35.599 --> 00:02:38.560
very, very different. Awesome. And Jack, can

00:02:38.560 --> 00:02:40.259
you introduce yourself, give a little bit about

00:02:40.259 --> 00:02:44.159
your background, what you do? Yeah, Jack Richens.

00:02:44.159 --> 00:02:48.740
I am the lead for the post -quantum transition

00:02:48.740 --> 00:02:53.060
team. But my other hat is I manage the Azure

00:02:53.060 --> 00:02:56.800
security key management team. So this is Azure

00:02:56.800 --> 00:03:00.780
Key Vault, managed HSM, cloud HSM, a bunch of

00:03:00.780 --> 00:03:03.639
products with HSM in their names. I've been around

00:03:03.639 --> 00:03:06.919
at Microsoft a long time in identity, a long

00:03:06.919 --> 00:03:11.460
time in SQL. Actually, Michael and I just kind

00:03:11.460 --> 00:03:13.639
of missed each other, I think, in SQL, but we

00:03:13.639 --> 00:03:17.039
both worked with a lot of the same people. I

00:03:17.039 --> 00:03:20.360
am also not a cryptographer in the sense that

00:03:20.360 --> 00:03:24.219
I implement crypto, but with key management,

00:03:24.340 --> 00:03:27.599
we turn it into a product. We take the modules

00:03:27.599 --> 00:03:30.580
that other people... make and then convert that

00:03:30.580 --> 00:03:32.759
into a product that people can use. And I think

00:03:32.759 --> 00:03:35.759
that's valuable in the PQC transition because

00:03:35.759 --> 00:03:38.500
as we get into it, the algorithms are figured

00:03:38.500 --> 00:03:40.960
out. It's really about how do we adopt them and

00:03:40.960 --> 00:03:43.460
roll them out. And that's something we do a lot

00:03:43.460 --> 00:03:47.120
of in our team. Awesome. Welcome to the podcast.

00:03:47.479 --> 00:03:51.719
Thank you. So let's start with, imagine that

00:03:51.719 --> 00:03:54.639
I know nothing or very little or only the basics

00:03:54.639 --> 00:03:57.800
of crypto. What is PQC? What is post -quantum

00:03:57.800 --> 00:04:02.349
cryptography? Behind it is you need to back up

00:04:02.349 --> 00:04:07.169
and understand crypto today. We use a ton of

00:04:07.169 --> 00:04:10.439
asymmetric cryptography. This is where you have

00:04:10.439 --> 00:04:12.759
a private and public key pair and they're related

00:04:12.759 --> 00:04:15.599
to each other, but you can safely expose the

00:04:15.599 --> 00:04:18.060
public key and no one can figure out what the

00:04:18.060 --> 00:04:21.279
private key is, at least not in the lifespan

00:04:21.279 --> 00:04:24.600
of the universe with traditional computers. And

00:04:24.600 --> 00:04:27.800
these asymmetric algorithms have names like elliptic

00:04:27.800 --> 00:04:31.980
curve or RSA, but they're using these public

00:04:31.980 --> 00:04:37.360
private key pairs. What's behind PQC is the algorithms

00:04:37.360 --> 00:04:42.060
we've been using. Some mathematicians proved

00:04:42.060 --> 00:04:45.639
that they could actually calculate the private

00:04:45.639 --> 00:04:48.920
key given the public key using a quantum computer.

00:04:49.160 --> 00:04:51.920
And quantum computers over the last several years,

00:04:52.000 --> 00:04:53.560
if you've been following the news, they're becoming

00:04:53.560 --> 00:04:56.379
more and more real. And people are actually implementing

00:04:56.379 --> 00:05:00.220
these algorithms. And it is now becoming very

00:05:00.220 --> 00:05:03.620
near term that we'll have a quantum computer

00:05:03.620 --> 00:05:06.540
that can literally calculate the private key.

00:05:07.000 --> 00:05:10.000
using a public key, using these traditional algorithms.

00:05:10.920 --> 00:05:16.360
And a post -quantum cryptography is a new algorithm.

00:05:17.199 --> 00:05:20.519
In most cases, AES is maybe a special case there,

00:05:20.620 --> 00:05:23.240
but usually it's a new algorithm or a set of

00:05:23.240 --> 00:05:27.220
algorithms that there's no known way to break

00:05:27.220 --> 00:05:31.829
them using a quantum computer. So NIST and the

00:05:31.829 --> 00:05:34.329
whole industry has been working on this for years

00:05:34.329 --> 00:05:37.189
and we have algorithms defined and now we're

00:05:37.189 --> 00:05:39.870
at the stage of it's time to go adopt them because

00:05:39.870 --> 00:05:43.050
quantum computers are really close. We've finalized

00:05:43.050 --> 00:05:45.209
these algorithms. We have high confidence in

00:05:45.209 --> 00:05:49.709
them. And now we have PQC algorithms that we

00:05:49.709 --> 00:05:52.230
can go and adopt. So you could say that is PQC.

00:05:52.889 --> 00:05:54.769
There's a simpler one if you want to make it

00:05:54.769 --> 00:05:58.389
really simple. I would point at CNSA 2 .0. That's

00:05:58.389 --> 00:06:02.180
a set of algorithms and cipher suites that NIST

00:06:02.180 --> 00:06:05.459
and NSA have worked together on and said, these

00:06:05.459 --> 00:06:07.779
are the ones that we do not believe a quantum

00:06:07.779 --> 00:06:11.459
computer can break and go do this. And so then

00:06:11.459 --> 00:06:13.199
that makes it very concrete. You don't have to

00:06:13.199 --> 00:06:15.680
understand the math. You want to know what PQC

00:06:15.680 --> 00:06:19.379
is, it's CNSA 2 .0 or your equivalent regulation

00:06:19.379 --> 00:06:25.379
in other countries. Gotcha. So essentially, crypto

00:06:25.379 --> 00:06:27.459
is all based on one -way math, right? You can

00:06:27.459 --> 00:06:30.129
go one way, but can't go back. asymmetric crypto

00:06:30.129 --> 00:06:33.670
asymmetric crypto yep and then you know essentially

00:06:33.670 --> 00:06:35.310
what we found is a quantum computer is going

00:06:35.310 --> 00:06:36.910
to turn that into two -way when they weren't

00:06:36.910 --> 00:06:39.370
supposed to be two -way and then correct that

00:06:39.370 --> 00:06:41.569
pretty much uh shakes the foundations of all

00:06:41.569 --> 00:06:44.730
security on the internet yeah okay cool just

00:06:44.730 --> 00:06:47.189
making sure i had the i had the net on that one

00:06:47.189 --> 00:06:50.209
um michael anything i well it's anything right

00:06:50.209 --> 00:06:52.730
it's not just it's not just like communications

00:06:52.730 --> 00:06:56.029
it's even things like crypto Like money. Oh,

00:06:56.029 --> 00:06:58.610
yeah, yeah. Or stored value, right? I mean, they

00:06:58.610 --> 00:07:01.410
all use asymmetric algorithms as well. So I really

00:07:01.410 --> 00:07:03.069
want to stress something here. And we will talk

00:07:03.069 --> 00:07:05.290
about algorithms a little bit later on. But to

00:07:05.290 --> 00:07:08.509
Jack's point, it is the asymmetric cryptographic

00:07:08.509 --> 00:07:11.470
algorithms that are at risk. And the real problem,

00:07:11.550 --> 00:07:14.129
what it really boils down to, is that you use

00:07:14.129 --> 00:07:16.790
asymmetric crypto, as Jack sort of mentioned,

00:07:16.930 --> 00:07:21.610
to wrap a symmetric key, like AES. Those keys,

00:07:22.009 --> 00:07:25.519
the AES keys, are, for the most part, There is

00:07:25.519 --> 00:07:28.379
a little nuance to it, but just humor me. For

00:07:28.379 --> 00:07:31.399
the most part, they're okay. But it's the asymmetric

00:07:31.399 --> 00:07:34.120
keys that become real problems. And the big ones

00:07:34.120 --> 00:07:36.920
by far are RSA, even though RSA has sort of fallen

00:07:36.920 --> 00:07:39.759
out of favor because of elliptic curve use in

00:07:39.759 --> 00:07:43.639
TLS 1 .3, for example. But elliptic curve is

00:07:43.639 --> 00:07:47.500
also at risk. And if you look at the math problems,

00:07:47.560 --> 00:07:51.120
to your point, Mark, RSA is all about factoring

00:07:51.120 --> 00:07:54.620
large numbers. And for elliptic curve, it's all

00:07:54.620 --> 00:07:56.600
about this discrete logarithm problem. It's very

00:07:56.600 --> 00:07:59.060
easy to go forward. With RSA, you can take two

00:07:59.060 --> 00:08:00.459
numbers and multiply them together and get a

00:08:00.459 --> 00:08:03.980
result. But if I give you a 700 -digit number,

00:08:04.139 --> 00:08:05.740
what are the factors? That's a very, very hard

00:08:05.740 --> 00:08:08.639
problem to solve unless you're a quantum computer.

00:08:09.000 --> 00:08:10.699
And some people have asked, what is it that makes

00:08:10.699 --> 00:08:13.720
quantum computers magic? They're not magic, but

00:08:13.720 --> 00:08:16.439
the analogy I like to use, and it's a terrible

00:08:16.439 --> 00:08:19.879
analogy, but it's pretty good, is if you got

00:08:19.879 --> 00:08:22.800
on a classic computer today, eight bits right

00:08:22.800 --> 00:08:25.420
so that can that that eight bits can hold between

00:08:25.420 --> 00:08:27.980
zero and 255 but it can only hold one number

00:08:27.980 --> 00:08:31.860
it's either like 127 or three or something right

00:08:31.860 --> 00:08:34.159
it's not all of them but in a qubit a quantum

00:08:34.159 --> 00:08:37.279
bit it can actually store all the values at the

00:08:37.279 --> 00:08:40.080
same time and that's called quantum superposition

00:08:40.080 --> 00:08:41.980
now i don't want to get into a whole quantum

00:08:41.980 --> 00:08:44.950
mechanics discussion because then we'll be totally

00:08:44.950 --> 00:08:48.049
go off the rails, but that's the thing that makes

00:08:48.049 --> 00:08:51.450
quantum computers so interesting is you've got

00:08:51.450 --> 00:08:54.490
this, you know, the ability to store all the

00:08:54.490 --> 00:08:57.049
same values at the same time. So it's sort of

00:08:57.049 --> 00:08:59.230
like, it's sort of like a multiverse. If you're

00:08:59.230 --> 00:09:01.590
looking, if you're like a fan of sci -fi or,

00:09:01.590 --> 00:09:03.210
you know, Marvel universe or whatever, it's,

00:09:03.210 --> 00:09:05.950
it's multiple things all happening at once. Correct.

00:09:06.450 --> 00:09:09.029
Yeah. Yeah. And then you observe the qubit and

00:09:09.029 --> 00:09:10.909
it collapses and blah, blah, blah, blah, blah.

00:09:10.950 --> 00:09:13.129
Right. Or quantum mumbo jumbo comes into play.

00:09:13.759 --> 00:09:17.879
But what's interesting is that there's lots of

00:09:17.879 --> 00:09:23.000
advances on both quantum computing itself and

00:09:23.000 --> 00:09:28.340
the other one is algorithms to defeat RSA. And

00:09:28.340 --> 00:09:30.139
the most well -known one is Shor's algorithm,

00:09:30.220 --> 00:09:33.399
which came out in the mid -90s, and that's spelled

00:09:33.399 --> 00:09:35.299
S -H -O -R. I won't provide a link to the research,

00:09:35.299 --> 00:09:38.360
but there's more to it than that. There's been

00:09:38.360 --> 00:09:41.070
a lot of research since Shor. that speed things

00:09:41.070 --> 00:09:42.809
up. So the problem we've got now is we've got

00:09:42.809 --> 00:09:44.610
constant computers becoming more and more real,

00:09:44.690 --> 00:09:46.629
and the algorithms becoming better and better

00:09:46.629 --> 00:09:47.669
and better. And in the middle, they're going

00:09:47.669 --> 00:09:51.029
to meet in the middle. And we believe that meet

00:09:51.029 --> 00:09:54.789
in the middle is very close. Yeah, so let's dive

00:09:54.789 --> 00:09:58.250
into that timing thing. So how urgent is this?

00:09:58.809 --> 00:10:01.870
And what is the timing of this is when it's going

00:10:01.870 --> 00:10:05.149
to become a real security problem? And when should

00:10:05.149 --> 00:10:07.049
I be starting to think about doing something

00:10:07.049 --> 00:10:09.179
about it or doing something? I think there's

00:10:09.179 --> 00:10:11.620
growing consensus, and you can look at some public

00:10:11.620 --> 00:10:14.879
announcements from some of our competitors, Google

00:10:14.879 --> 00:10:16.759
and others, but I think there's growing consensus

00:10:16.759 --> 00:10:21.379
that it could happen in 2030, that we could have

00:10:21.379 --> 00:10:24.759
a cryptographically relevant quantum computer.

00:10:24.860 --> 00:10:27.919
And the other term that's used is a Q date, is

00:10:27.919 --> 00:10:30.740
the date that a quantum computer can exist that

00:10:30.740 --> 00:10:34.940
breaks crypto. So that's a date, but it's more

00:10:34.940 --> 00:10:37.220
nuanced than that. So that's the date when the

00:10:37.220 --> 00:10:39.480
quantum computer exists. But what a lot of people

00:10:39.480 --> 00:10:44.440
don't have to face the reality of is a lot of

00:10:44.440 --> 00:10:47.220
our communications, our transactions, our data

00:10:47.220 --> 00:10:52.940
has to be resilient against crypto attacks for

00:10:52.940 --> 00:10:57.679
more than just this instant moment. There's this

00:10:57.679 --> 00:10:59.940
attack called harvest now, decrypt later, where

00:10:59.940 --> 00:11:03.559
people could just harvest network traffic. or

00:11:03.559 --> 00:11:07.500
capture stolen encrypted data, and it would still

00:11:07.500 --> 00:11:11.519
have high value years later. NIST and NSA, they've

00:11:11.519 --> 00:11:14.159
made statements around a lot of government data

00:11:14.159 --> 00:11:17.879
needs to be protected for 10 to 15 years. So

00:11:17.879 --> 00:11:21.019
they're already today in that harvest now decrypt

00:11:21.019 --> 00:11:25.080
later window for quantum computers, where if

00:11:25.080 --> 00:11:28.980
an attacker grabs the data today, it's likely

00:11:28.980 --> 00:11:32.580
still valuable in three or four years until a

00:11:32.580 --> 00:11:34.960
quantum computer shows up because we're within

00:11:34.960 --> 00:11:39.059
that 10 to 15 year window. So as we dig into

00:11:39.059 --> 00:11:42.019
the details, some of the crypto needs to change

00:11:42.019 --> 00:11:45.440
now. It should have changed yesterday, but yesterday's

00:11:45.440 --> 00:11:48.600
passed. So we've got to do it now. And there's

00:11:48.600 --> 00:11:52.419
some other stuff that can wait until 2030. But

00:11:52.419 --> 00:11:54.519
as you start digging into the details and the

00:11:54.519 --> 00:11:58.389
size of the problem and where we use it. Even

00:11:58.389 --> 00:12:01.250
for those things that can afford to wait for

00:12:01.250 --> 00:12:04.629
the transition to complete until 2030, you probably

00:12:04.629 --> 00:12:07.429
need to start doing stuff on that now as well.

00:12:07.750 --> 00:12:09.429
Well, there's a thing called Mosca's theorem,

00:12:09.549 --> 00:12:11.929
right? Which is basically if the migration time

00:12:11.929 --> 00:12:16.990
plus the sensitivity of the data shelf life exceeds

00:12:16.990 --> 00:12:20.009
queue day, as you put it, then you're already

00:12:20.009 --> 00:12:23.850
exposed. Because that means the data is still

00:12:23.850 --> 00:12:27.860
valid or still should remain sensitive. after

00:12:27.860 --> 00:12:30.220
Q Day, you know, to your point, like military

00:12:30.220 --> 00:12:34.120
information, what about trade secrets? You know,

00:12:34.159 --> 00:12:37.059
imagine you're your favorite, you know, company

00:12:37.059 --> 00:12:39.000
that creates your favorite soda and they've got,

00:12:39.019 --> 00:12:40.860
they protected their recipes with trade secrets

00:12:40.860 --> 00:12:44.620
and they're using classical key wrapping today

00:12:44.620 --> 00:12:48.620
could be broken and, you know, post Q Day. Or

00:12:48.620 --> 00:12:53.230
privacy data and fines around that, right? The

00:12:53.230 --> 00:12:55.710
EU's not going to care that it was taken four

00:12:55.710 --> 00:12:59.409
years ago. They'll care that EU citizen data

00:12:59.409 --> 00:13:02.549
was exposed. Yeah, so it's essentially the attackers

00:13:02.549 --> 00:13:05.450
essentially grab a copy of the lockbox, and then

00:13:05.450 --> 00:13:07.850
they have a couple years to pick it, and it's

00:13:07.850 --> 00:13:10.210
still valuable when they crack open that lockbox.

00:13:11.009 --> 00:13:17.269
Right, right. So, clear message, start now. The

00:13:17.269 --> 00:13:21.889
next question is, what do I start? Yeah. I mean,

00:13:21.929 --> 00:13:25.950
Jack just answered that. Yeah. Well, I want to

00:13:25.950 --> 00:13:29.710
revisit because the space is so huge. It can

00:13:29.710 --> 00:13:35.049
be overwhelming. And I tend to bucketize it into

00:13:35.049 --> 00:13:41.240
data in transit, data at rest. Cryptographic

00:13:41.240 --> 00:13:44.879
trust is the term I use. There's maybe not a

00:13:44.879 --> 00:13:47.279
standard of a term in the industry for that third

00:13:47.279 --> 00:13:50.379
bucket. But in transit, I think should be obvious

00:13:50.379 --> 00:13:54.840
to everyone that any network communications are

00:13:54.840 --> 00:13:58.159
at risk of being copied out. And so in my mind,

00:13:58.179 --> 00:14:02.700
that's the top risk. And there we can break it

00:14:02.700 --> 00:14:05.860
down even more. When we talk about data in transit,

00:14:05.960 --> 00:14:10.240
there's two parts to TLS. There's the encryption.

00:14:10.809 --> 00:14:14.149
that keeps the data confidential. And then there's

00:14:14.149 --> 00:14:17.429
authentication that says, I know who you are

00:14:17.429 --> 00:14:21.789
and you know who I am. And I know this message

00:14:21.789 --> 00:14:26.830
came from you. The part that's at risk for HarvestNow

00:14:26.830 --> 00:14:30.730
decrypt later is the encryption in transit. And

00:14:30.730 --> 00:14:32.629
as Michael mentioned, the actual data encryption

00:14:32.629 --> 00:14:34.950
is already done using AES. That's the good news.

00:14:35.169 --> 00:14:38.750
So if you're on TLS 1 .3. Good job. You got that

00:14:38.750 --> 00:14:42.710
part. But to exchange the symmetric keys, they

00:14:42.710 --> 00:14:45.529
have to do this key establishment dance. Right

00:14:45.529 --> 00:14:48.370
now, that's using elliptic curve. And that needs

00:14:48.370 --> 00:14:52.490
to move to MLChem as the PQ algorithm for key

00:14:52.490 --> 00:14:58.029
establishment in CNSA 2 .0. So in my mind, that's

00:14:58.029 --> 00:15:03.259
the top most urgent risk. At rest. is also risky,

00:15:03.419 --> 00:15:06.759
although usually at rest is somewhat defense

00:15:06.759 --> 00:15:09.500
in depth, depending on your environment and applications.

00:15:10.059 --> 00:15:12.440
And so there may be other mitigating controls

00:15:12.440 --> 00:15:16.059
that you can still rely on, even if the crypto

00:15:16.059 --> 00:15:19.539
is broken. So I put it like a click stop below

00:15:19.539 --> 00:15:23.080
in transit. And then the last one, the cryptographic

00:15:23.080 --> 00:15:27.679
trust. Technically, I don't think there's an

00:15:27.679 --> 00:15:32.139
attack that you can leverage until Q date. The

00:15:32.139 --> 00:15:34.620
problem is, as we start unwinding cryptographic

00:15:34.620 --> 00:15:37.100
trusts, those are the components that are long

00:15:37.100 --> 00:15:39.100
-lived. To Michael's point earlier, it takes

00:15:39.100 --> 00:15:42.539
a long time to transition them. So the attack

00:15:42.539 --> 00:15:44.279
won't happen for a while, but the transition

00:15:44.279 --> 00:15:46.759
is lengthy, and there's a lot of work there.

00:15:47.340 --> 00:15:48.960
Yeah, I don't have a lot to add to that, but

00:15:48.960 --> 00:15:52.019
I do agree the in -transit aspect is by far the

00:15:52.019 --> 00:15:56.509
most risky in terms of the threat today. If you're

00:15:56.509 --> 00:15:58.809
talking between point A and point B, you don't

00:15:58.809 --> 00:16:00.610
know who's listening. You've got no clue whatsoever.

00:16:01.289 --> 00:16:04.049
And then when you've got data at rest, as you

00:16:04.049 --> 00:16:05.590
point out, you've probably got other defenses

00:16:05.590 --> 00:16:09.049
as well. Access control, authorization, authentication,

00:16:09.450 --> 00:16:12.389
and lots of other controls as well. So yeah,

00:16:12.429 --> 00:16:15.389
the big one by far is in transit. And the cryptographic

00:16:15.389 --> 00:16:17.289
trust one is really interesting because it's,

00:16:17.289 --> 00:16:21.210
to your point, not only is it potentially long

00:16:21.210 --> 00:16:22.909
-lived things, like for example digital signatures

00:16:22.909 --> 00:16:26.250
on binaries, Some of those roots of trust may

00:16:26.250 --> 00:16:29.370
actually be in hardware. And now you've got a

00:16:29.370 --> 00:16:31.470
hardware issue where you've got to start having

00:16:31.470 --> 00:16:34.690
some of these post -quantum algorithms in hardware,

00:16:34.990 --> 00:16:37.529
or software on the hardware, or something. But

00:16:37.529 --> 00:16:39.649
at the end of the day, it ends up being a real

00:16:39.649 --> 00:16:42.450
important root of trust as well. The way I've

00:16:42.450 --> 00:16:46.649
been thinking about this, from the, what do I

00:16:46.649 --> 00:16:49.330
tell my technology team, or what do I do as a

00:16:49.330 --> 00:16:51.470
technology professional or security professional?

00:16:52.269 --> 00:16:55.590
I mean, this strikes me as being extremely similar

00:16:55.590 --> 00:16:58.490
to a software update and patching process because

00:16:58.490 --> 00:17:02.450
at the end of the day, the algorithms are just

00:17:02.450 --> 00:17:04.410
little bits of software that are implemented,

00:17:04.589 --> 00:17:07.470
right? And so I just have to update all the things

00:17:07.470 --> 00:17:10.190
that use TLS and all the things that are doing

00:17:10.190 --> 00:17:13.049
encryption, etc. I mean, is that the right perspective

00:17:13.049 --> 00:17:17.490
or is that too narrow or naive? I think that's

00:17:17.490 --> 00:17:20.609
the right place to start. For the majority of...

00:17:21.559 --> 00:17:25.839
scenarios, that's where you start. And certainly

00:17:25.839 --> 00:17:30.460
it addresses TLS. It does get more complicated.

00:17:30.680 --> 00:17:33.500
I view it as there's like a long tail of complexity

00:17:33.500 --> 00:17:36.440
here in custom applications and custom crypto,

00:17:36.460 --> 00:17:39.359
and that kind of transitions into crypto agility.

00:17:40.240 --> 00:17:42.420
As cryptography is spread through everything

00:17:42.420 --> 00:17:46.059
we do in computing, there are examples where

00:17:46.059 --> 00:17:48.880
they did it in a very crypto -agile manner, like

00:17:48.880 --> 00:17:52.019
TLS, where there's a standard protocol, there's

00:17:52.019 --> 00:17:54.779
negotiation between the client and server, and

00:17:54.779 --> 00:17:57.920
you push out configs. So to your point with TLS...

00:17:58.269 --> 00:18:00.809
If you go update to the latest version of your

00:18:00.809 --> 00:18:05.470
operating systems and your network stack, it

00:18:05.470 --> 00:18:08.009
probably already supports TLS 1 .3 without you

00:18:08.009 --> 00:18:11.890
having to do anything. And as PQ algorithms roll

00:18:11.890 --> 00:18:14.529
out like MLChem, they'll just be added to the

00:18:14.529 --> 00:18:17.950
Cypher suite. And so you can treat it just like

00:18:17.950 --> 00:18:20.890
a vulnerability patching, right? Just update,

00:18:21.109 --> 00:18:27.029
deploy, you're done. The long tail gets messy.

00:18:27.690 --> 00:18:29.670
And that's where we start having to do inventory.

00:18:30.069 --> 00:18:31.930
And then there's stuff that's kind of in between,

00:18:31.990 --> 00:18:36.670
like PKI, CA routes. I've lived through a couple

00:18:36.670 --> 00:18:41.009
of CA route rotations, and they're surprisingly

00:18:41.009 --> 00:18:44.809
complex to navigate for an organization. And

00:18:44.809 --> 00:18:47.710
it takes a lot of work. And I think we're effectively

00:18:47.710 --> 00:18:50.750
going to have to see most routes rotate over

00:18:50.750 --> 00:18:54.109
the next couple of years. Sir, there is a real

00:18:54.109 --> 00:18:57.789
fly in the ointment there. And that is the signature

00:18:57.789 --> 00:19:03.109
sizes and the resulting ciphertext sizes. Oh,

00:19:03.130 --> 00:19:06.329
yeah. Who wants to say the bad news? Me or you,

00:19:06.430 --> 00:19:10.490
Jack? You can say it. Oh, thank you. The size

00:19:10.490 --> 00:19:12.970
of the resulting signatures or ciphertext, whatever,

00:19:13.069 --> 00:19:17.289
is huge. Or the key wrapping blob is huge relative

00:19:17.289 --> 00:19:22.210
to the size of, say, an AES wrapped with an elliptic

00:19:22.210 --> 00:19:27.990
curve. Signatures are a lot bigger as well. that's

00:19:27.990 --> 00:19:30.509
going to cause problems for some people. And

00:19:30.509 --> 00:19:34.690
for example, the TLS handshake ends up being

00:19:34.690 --> 00:19:37.630
bigger, substantially bigger. And there may be

00:19:37.630 --> 00:19:39.710
performance implications of that. Now, luckily,

00:19:39.789 --> 00:19:41.890
it only happens once at the beginning when the

00:19:41.890 --> 00:19:44.789
handshake is done and client hello, server hello,

00:19:44.950 --> 00:19:46.769
and they finally establish the keying material.

00:19:47.289 --> 00:19:51.690
But I'm very glad you said TLS keys before not

00:19:51.690 --> 00:19:54.420
key. It's amazing how many people think there's

00:19:54.420 --> 00:19:56.539
one key. There's actually not. There's like,

00:19:56.599 --> 00:19:58.900
isn't that like eight keys or something that

00:19:58.900 --> 00:20:00.420
was established between the two for different,

00:20:00.480 --> 00:20:04.839
for A to B, B to A encryption and a Mac if you're

00:20:04.839 --> 00:20:06.619
using an HMAC or something like that. There's

00:20:06.619 --> 00:20:08.180
a couple, an initialization vector, I think.

00:20:08.200 --> 00:20:09.640
There's a few others as well. It's not just a

00:20:09.640 --> 00:20:14.160
key. Anyway, yeah, the key point, no pun intended,

00:20:14.220 --> 00:20:16.339
is that people need to be aware of the fact that

00:20:16.339 --> 00:20:20.460
the resulting cipher blob, whether it's a signature

00:20:20.460 --> 00:20:24.849
or a key wrapping, is significantly larger than

00:20:24.849 --> 00:20:26.970
what we're used to today. And that might cause

00:20:26.970 --> 00:20:28.609
problems, especially on some of the downstream

00:20:28.609 --> 00:20:32.349
hardware. Also, we're seeing issues where some

00:20:32.349 --> 00:20:34.289
of that data is passed on a query string and

00:20:34.289 --> 00:20:37.710
some browsers or some intermediate HTTPS stacks

00:20:37.710 --> 00:20:41.890
don't like it because it's too big. So the whole

00:20:41.890 --> 00:20:44.269
industry is going to get a real shakeout. My

00:20:44.269 --> 00:20:47.250
analogy for this is it's a lot like the Y2K problem.

00:20:47.369 --> 00:20:50.200
It's coming up whether we like it or not. And

00:20:50.200 --> 00:20:52.140
a lot of work needs to be done in a lot of places,

00:20:52.299 --> 00:20:54.400
including identifying where these places are

00:20:54.400 --> 00:20:57.460
before you can fix them. But I think the overall

00:20:57.460 --> 00:21:01.700
potential for regressions is actually quite high

00:21:01.700 --> 00:21:07.059
relative to smaller changes, even like Y2K, which

00:21:07.059 --> 00:21:10.180
went off smoothly. But it only went off smoothly

00:21:10.180 --> 00:21:12.539
because everyone did so much work. So what are

00:21:12.539 --> 00:21:14.279
your thoughts about that, Jack, with the size

00:21:14.279 --> 00:21:16.000
of these signatures or the size of the key wrapping

00:21:16.000 --> 00:21:19.380
blobs? Where do you see issues? Yeah, well, two

00:21:19.380 --> 00:21:21.500
things. I'll make it a little bit worse, and

00:21:21.500 --> 00:21:24.940
then I'm going to share some good news. The worst

00:21:24.940 --> 00:21:27.440
part is the size. What a lot of people don't

00:21:27.440 --> 00:21:29.400
realize is it's not merely that there's more

00:21:29.400 --> 00:21:32.759
data being transmitted, but now it ends up being

00:21:32.759 --> 00:21:37.400
spread over multiple packets. And that introduces

00:21:37.400 --> 00:21:40.259
challenges with packets showing up out of order

00:21:40.259 --> 00:21:45.519
or getting stuck and taking longer to get to

00:21:45.519 --> 00:21:50.160
the destination. and breaking a part of the protocol

00:21:50.160 --> 00:21:52.859
that we're used to going really fast now. We're

00:21:52.859 --> 00:21:56.400
not in the days of dial -up modems where that

00:21:56.400 --> 00:21:59.900
negotiation was expected to take multiple seconds.

00:21:59.980 --> 00:22:02.859
Now everyone's used to that just happening. And

00:22:02.859 --> 00:22:07.190
I think there's a very real fear that... Some

00:22:07.190 --> 00:22:09.009
software is going to break. They're going to

00:22:09.009 --> 00:22:11.450
have to change some of their timings and become

00:22:11.450 --> 00:22:13.690
more resilient to deal with these larger sizes.

00:22:14.150 --> 00:22:19.170
There's also challenges with some of the hardware

00:22:19.170 --> 00:22:22.289
because some of the, you mentioned code signing,

00:22:22.349 --> 00:22:25.130
so it's not just TLS, but there's code signing.

00:22:26.410 --> 00:22:29.309
There's multiple algorithms there that they can

00:22:29.309 --> 00:22:31.890
use for signing, but some of them like MLDSA

00:22:31.890 --> 00:22:36.240
result in really large signatures. They have

00:22:36.240 --> 00:22:38.660
challenges cramming the algorithm and the signatures

00:22:38.660 --> 00:22:40.700
into hardware. There's not room for multiple

00:22:40.700 --> 00:22:43.680
signatures, which is another challenge there.

00:22:43.839 --> 00:22:47.619
So that's kind of the even worse news. I think

00:22:47.619 --> 00:22:50.619
the only thing I would say, because I don't want

00:22:50.619 --> 00:22:56.140
to scare anyone away from TLS 1 .3, is all of

00:22:56.140 --> 00:23:00.799
those issues around signing, etc., they primarily

00:23:00.799 --> 00:23:06.200
implicate... authentication, cryptographic trust,

00:23:06.339 --> 00:23:08.920
and not the actual data encryption. And the way

00:23:08.920 --> 00:23:11.819
TLS 1 .3 breaks up the protocol, those cipher

00:23:11.819 --> 00:23:14.579
suites can be rolled out independently of the

00:23:14.579 --> 00:23:18.259
certificates that identify the server. And there's

00:23:18.259 --> 00:23:20.859
been very good testing in the industry and with

00:23:20.859 --> 00:23:24.740
Microsoft and with our own stack, TLS 1 .3 with

00:23:24.740 --> 00:23:29.859
the key exchange that preserves your confidentiality.

00:23:30.430 --> 00:23:32.710
that's going well. The software is dealing with

00:23:32.710 --> 00:23:35.809
that well. We don't see issues there. You shouldn't

00:23:35.809 --> 00:23:38.349
see perf issues. So don't be afraid to go roll

00:23:38.349 --> 00:23:40.569
out what the industry is rolling out now. You

00:23:40.569 --> 00:23:43.569
can go look at endpoints and you'll see endpoints

00:23:43.569 --> 00:23:49.210
offering TLS 1 .3 with elliptic curve hybrid

00:23:49.210 --> 00:23:52.170
with MLChem. So it's doing a double encryption

00:23:52.170 --> 00:23:56.519
and it performs fine. And go do that now. Protect

00:23:56.519 --> 00:24:00.019
your data in transit. Cryptographic trust, those

00:24:00.019 --> 00:24:04.359
signing operations and the signatures are huge.

00:24:04.720 --> 00:24:07.140
Yes, that's big and scary and risky, but we have

00:24:07.140 --> 00:24:09.710
some time to go work through that. Do you want

00:24:09.710 --> 00:24:10.829
to talk about the hybrid in a little bit more

00:24:10.829 --> 00:24:12.829
detail? Because I think that's really important.

00:24:13.289 --> 00:24:16.869
Yeah. So I guess double encryption is, I wouldn't

00:24:16.869 --> 00:24:20.049
say it's wrong, but it's an ambiguous term. And

00:24:20.049 --> 00:24:23.089
you've done a bunch of research into this as

00:24:23.089 --> 00:24:25.430
well, Michael. But the high -level concept is,

00:24:25.650 --> 00:24:28.470
you mentioned there's multiple keys. They literally

00:24:28.470 --> 00:24:34.599
have two keys to do the key establishment. elliptic

00:24:34.599 --> 00:24:37.279
curve. They still use an elliptic curve key and

00:24:37.279 --> 00:24:39.940
they have an MLChem key. They're different keys

00:24:39.940 --> 00:24:45.519
and they're encrypting two different symmetric

00:24:45.519 --> 00:24:48.359
keys that are then going to actually encrypt

00:24:48.359 --> 00:24:53.819
the data so that in order to break an TLS 1 .3

00:24:53.819 --> 00:24:58.160
stream that's been hybrid encrypted in this manner,

00:24:58.279 --> 00:25:02.140
you have to compromise elliptic curve. and MLChem.

00:25:02.180 --> 00:25:04.279
And the reason the industry wants to do this

00:25:04.279 --> 00:25:07.140
is, while we know quantum computers are coming,

00:25:07.339 --> 00:25:10.599
that's a probabilistic statement because it's

00:25:10.599 --> 00:25:15.000
still in the future. And conversely, MLChem and

00:25:15.000 --> 00:25:17.559
all of these PQ algorithms, while they've been

00:25:17.559 --> 00:25:23.619
really tested well by NIST, NSA, Academia, cryptographers

00:25:23.619 --> 00:25:27.180
around the world they're new and cryptographers

00:25:27.180 --> 00:25:30.079
are a paranoid bunch and they're like yeah all

00:25:30.079 --> 00:25:32.380
it takes is for someone to come along and approach

00:25:32.380 --> 00:25:34.480
the problem in a unique way we never thought

00:25:34.480 --> 00:25:38.099
of and they might find flaws here and so right

00:25:38.099 --> 00:25:41.799
now the guidance is do some kind of hybrid composite

00:25:41.799 --> 00:25:46.359
scheme where you have to break both a traditional

00:25:46.359 --> 00:25:49.859
algorithm that is a known quantity and resilient

00:25:49.859 --> 00:25:52.380
against traditional computers, and you have to

00:25:52.380 --> 00:25:57.279
break the quantum -resistant algorithm. So it's

00:25:57.279 --> 00:25:59.660
almost like the cryptographic version of a two

00:25:59.660 --> 00:26:01.759
-person rule or a two -man rule, right? Yeah.

00:26:01.859 --> 00:26:04.539
Where you can get one, but that doesn't get you

00:26:04.539 --> 00:26:07.900
both. Right. And we're forcing you to break both

00:26:07.900 --> 00:26:10.940
as much as possible. I think with the key sizes

00:26:10.940 --> 00:26:14.559
and hardware, we're running into situations where

00:26:14.559 --> 00:26:16.960
that's not possible. But wherever we can do it

00:26:16.960 --> 00:26:20.279
in software or in other areas, we're trying to

00:26:20.279 --> 00:26:23.920
implement that two -man rule. And NIST is still

00:26:23.920 --> 00:26:27.119
doing research, right, on other algorithms. Because,

00:26:27.200 --> 00:26:29.039
as you say, the new algorithms, which we will

00:26:29.039 --> 00:26:32.329
talk about a little bit later on. are new and

00:26:32.329 --> 00:26:34.829
we don't know what's around the corner right

00:26:34.829 --> 00:26:36.630
and if all of a sudden something's found out

00:26:36.630 --> 00:26:39.730
we may need to move on to tls 1 .3 with new algorithms

00:26:39.730 --> 00:26:43.109
who knows yeah and like you mentioned before

00:26:43.109 --> 00:26:49.009
like elliptic curve and um and rsa they're both

00:26:49.009 --> 00:26:52.109
founded on certain one -way math problems like

00:26:52.109 --> 00:26:55.430
the prime numbers the new crypto algorithms that

00:26:55.430 --> 00:26:57.750
they introduced and i love to talk about their

00:26:57.750 --> 00:26:59.450
names that everyone's forgotten the code names

00:26:59.450 --> 00:27:01.970
already but they're all based off of lattice

00:27:01.970 --> 00:27:07.910
mathematics and that so that's fun that's neat

00:27:07.910 --> 00:27:11.309
um and the code names for the original algorithms

00:27:11.309 --> 00:27:14.829
were Kyber and Dilithium, so it's Star Wars and

00:27:14.829 --> 00:27:18.829
Star Trek. And then when they came up with the

00:27:18.829 --> 00:27:21.309
official names, they kept the first initial.

00:27:21.509 --> 00:27:26.869
So Dilithium became MLDSA and Kyber became MLKEM

00:27:26.869 --> 00:27:30.519
for key establishment. key establishment mechanism.

00:27:31.019 --> 00:27:34.279
So somebody there did their work so they could

00:27:34.279 --> 00:27:38.920
have the names make sense, but also pay homage

00:27:38.920 --> 00:27:42.259
to Star Wars and Star Trek. But they're both

00:27:42.259 --> 00:27:44.660
based on lattice. And so then the fear is, well,

00:27:44.740 --> 00:27:47.660
we've really studied it. We don't know how to

00:27:47.660 --> 00:27:51.660
break this now, but what happens tomorrow? And

00:27:51.660 --> 00:27:55.960
so they're continuing to research other mathematics

00:27:55.960 --> 00:27:59.339
that they could use for this. and algorithms

00:27:59.339 --> 00:28:03.000
based on those maths also the keys the sizes

00:28:03.000 --> 00:28:05.339
like they they've heard the feedback from the

00:28:05.339 --> 00:28:07.359
industry and they're trying to see if there's

00:28:07.359 --> 00:28:09.859
something they can do to get the sizes down so

00:28:09.859 --> 00:28:12.559
there continues to be research there so i have

00:28:12.559 --> 00:28:15.839
a really terrible analogy for lattice um crypto

00:28:15.839 --> 00:28:20.960
um but you know i i'm fine with terrible analogies

00:28:20.960 --> 00:28:22.779
as long as it gives you at least a mental model

00:28:22.779 --> 00:28:25.700
for what the problem is um so imagine if you

00:28:25.700 --> 00:28:28.049
have a chess board and you have a knight on the

00:28:28.049 --> 00:28:33.190
chessboard. If I tell you to move two up, one

00:28:33.190 --> 00:28:37.670
right, one down, two left, or something, and

00:28:37.670 --> 00:28:39.829
keep doing that, you can get to a certain point.

00:28:41.390 --> 00:28:43.029
Now imagine if I give you a chessboard and say,

00:28:43.130 --> 00:28:44.849
hey, here's a knight on a certain position. How

00:28:44.849 --> 00:28:49.089
do you get to that point? And you don't know.

00:28:49.170 --> 00:28:51.250
It's almost kind of like trial and error. It's

00:28:51.250 --> 00:28:52.930
like, how do you actually get to that end point?

00:28:53.150 --> 00:28:54.450
You may think, well, that's really easy on a

00:28:54.450 --> 00:28:57.279
chessboard. It is. But imagine... not two dimensions,

00:28:57.480 --> 00:29:03.880
but imagine 500 dimensions with lines, vectors

00:29:03.880 --> 00:29:08.019
that are more than two and one. And also you

00:29:08.019 --> 00:29:10.359
introduce a little bit of error in there as well.

00:29:10.779 --> 00:29:13.920
That's kind of how lattices work, kind of. It's

00:29:13.920 --> 00:29:15.960
very easy to move forward, like in other words,

00:29:15.980 --> 00:29:17.859
to get to a point and then say, hey, here's my

00:29:17.859 --> 00:29:20.640
point. But it's very difficult to say, here's

00:29:20.640 --> 00:29:22.660
my point. How do I get back to this other, this

00:29:22.660 --> 00:29:25.539
starting point with these nights or these vectors?

00:29:26.200 --> 00:29:28.500
So that's kind of what the problem is. And to

00:29:28.500 --> 00:29:31.779
your point, Jack, we believe it's quantum safe

00:29:31.779 --> 00:29:33.539
and we believe it's fine, but what happens if

00:29:33.539 --> 00:29:36.240
someone does some research? Things only get better

00:29:36.240 --> 00:29:39.359
and faster. What happens if we find out 10 years

00:29:39.359 --> 00:29:43.680
from now that we were dead wrong? So, yeah. Yeah.

00:29:44.720 --> 00:29:47.220
And kind of thinking about it from the practical

00:29:47.220 --> 00:29:51.359
standpoint, if I'm running a CISO or CIO or someone

00:29:51.359 --> 00:29:53.299
in a technology or security team that has to

00:29:53.299 --> 00:29:57.529
kind of figure this out, I think about that crypto

00:29:57.529 --> 00:30:00.730
agility term, which is I have to expect that

00:30:00.730 --> 00:30:04.289
maybe algorithm A didn't cut it or Kyber to Lithium

00:30:04.289 --> 00:30:07.190
didn't cut it and now we have a new version,

00:30:07.309 --> 00:30:09.789
a V2 or V3 of that or something else entirely.

00:30:14.170 --> 00:30:16.150
That's part of what it is is you've got to just

00:30:16.150 --> 00:30:19.329
get on this point where Crypto isn't, hey, we

00:30:19.329 --> 00:30:22.630
settled it and now we're good for 30 years. We

00:30:22.630 --> 00:30:25.210
have to keep updating it just like we do any

00:30:25.210 --> 00:30:28.690
other software vulnerability. Exactly. And that

00:30:28.690 --> 00:30:32.190
transitions nicely into the crypto agility discussion

00:30:32.190 --> 00:30:37.789
we were having earlier. There are well -trod

00:30:37.789 --> 00:30:41.869
patterns where we have really good crypto agility,

00:30:42.109 --> 00:30:47.710
like TLS. quickly say, hey, everyone, just stay

00:30:47.710 --> 00:30:51.789
up to date on TLS and the cipher suites are going

00:30:51.789 --> 00:30:53.710
to roll out and you're going to be fine. And

00:30:53.710 --> 00:30:55.670
it's just patches, just like a vulnerability

00:30:55.670 --> 00:30:59.289
versus kind of the long tail of cryptography

00:30:59.289 --> 00:31:01.230
where people have gone out and built their own

00:31:01.230 --> 00:31:07.049
thing. They have to go rebuild it. And if they

00:31:07.049 --> 00:31:10.069
continue to do custom crypto, they could go switch

00:31:10.069 --> 00:31:14.180
it to use MLChem and MLDSA. And five years from

00:31:14.180 --> 00:31:16.039
now, they could have to come back and do it again.

00:31:16.180 --> 00:31:19.859
And in my mind, now is the time to prune that

00:31:19.859 --> 00:31:23.480
long tail and wherever possible, abandon non

00:31:23.480 --> 00:31:27.420
-standard protocols, use TLS, abandon custom

00:31:27.420 --> 00:31:30.119
libraries that are doing your crypto, use standard

00:31:30.119 --> 00:31:33.039
encryption libraries that are well maintained

00:31:33.039 --> 00:31:36.920
so that you have somebody doing that. crypto

00:31:36.920 --> 00:31:40.640
agility work for you and it's turned into a vulnerability

00:31:40.640 --> 00:31:44.359
patching problem rather than go hire an engineer,

00:31:44.599 --> 00:31:49.960
do exhaustive research of your code base and

00:31:49.960 --> 00:31:53.279
rewrite it to support some new algorithm that's

00:31:53.279 --> 00:31:56.200
just too expensive, too painful. You'll make

00:31:56.200 --> 00:32:00.160
mistakes. You'll introduce regressions. We got

00:32:00.160 --> 00:32:03.119
to cut off that tail and move to standard protocols

00:32:03.119 --> 00:32:06.859
in crypto. Yeah, it's just like when people were

00:32:06.859 --> 00:32:08.619
starting to adopt cloud, it's to configure before

00:32:08.619 --> 00:32:12.799
customize. If you don't need specific custom

00:32:12.799 --> 00:32:15.539
crypto implementations, use the standard well

00:32:15.539 --> 00:32:18.559
-tested stuff. And please, please, please don't

00:32:18.559 --> 00:32:22.539
roll your own crypto. I mean, sometimes you need

00:32:22.539 --> 00:32:24.599
to manage your own route. You have certain things.

00:32:24.700 --> 00:32:27.339
But if you don't have to handle the plutonium

00:32:27.339 --> 00:32:29.440
with your bare hands or remember to put the gloves

00:32:29.440 --> 00:32:33.910
on, try not to. And I think it's that next level

00:32:33.910 --> 00:32:35.829
of it, because I think that was the mantra when

00:32:35.829 --> 00:32:39.309
STL was rolling out. Never implement AES. Go

00:32:39.309 --> 00:32:41.849
use the standard implementation. And I feel like

00:32:41.849 --> 00:32:45.329
this experience of the PQ transition is taking

00:32:45.329 --> 00:32:47.329
that the next level up. Not only should you not

00:32:47.329 --> 00:32:50.549
implement AES, you should try to use libraries

00:32:50.549 --> 00:32:52.769
where you don't even have to know AES is being

00:32:52.769 --> 00:32:55.569
used. You're calling some function that just

00:32:55.569 --> 00:33:00.150
says encrypt. And it's figuring out the right

00:33:00.150 --> 00:33:03.779
thing to do. So I had one last question, because

00:33:03.779 --> 00:33:07.859
as you were mentioning, we've got larger sets

00:33:07.859 --> 00:33:10.980
of data being produced, used, calculated, etc.,

00:33:10.980 --> 00:33:12.519
which is going to take more processing, more

00:33:12.519 --> 00:33:15.119
memory, etc. It feels like there's going to be,

00:33:15.259 --> 00:33:17.160
as part of that sort of long tail of problems,

00:33:17.299 --> 00:33:20.640
you've got IoT devices like cameras and crop

00:33:20.640 --> 00:33:23.119
sensors and all that kind of stuff that... Even

00:33:23.119 --> 00:33:25.700
if you could update them, they might not have

00:33:25.700 --> 00:33:28.440
the juice to actually do these kind of operations.

00:33:28.819 --> 00:33:31.059
Is that a correct assumption in that there might

00:33:31.059 --> 00:33:33.920
just be some either isolate them like OT devices

00:33:33.920 --> 00:33:37.299
or e -waste sort of issues? I'd love to hear

00:33:37.299 --> 00:33:40.099
your thoughts on that. I have thoughts. I'm not

00:33:40.099 --> 00:33:44.980
sure I have answers. I think there is a risk

00:33:44.980 --> 00:33:49.779
there. I think vendors have gotten better over

00:33:49.779 --> 00:33:52.849
the years at making their hardware a little bit

00:33:52.849 --> 00:33:55.430
more upgradable. And I've heard some good news

00:33:55.430 --> 00:33:58.569
about some components that we've looked into

00:33:58.569 --> 00:34:01.170
where we didn't think they'd ever be able to

00:34:01.170 --> 00:34:04.190
update and they are able to update to the PQ

00:34:04.190 --> 00:34:09.690
algorithm. So it's not as bad as I feared. I

00:34:09.690 --> 00:34:12.090
think a second mitigation is, although we talk

00:34:12.090 --> 00:34:15.349
about the Q date and in abstract terms you can

00:34:15.349 --> 00:34:18.329
assign a single date to it in more practical

00:34:18.329 --> 00:34:21.030
terms kind of like the vulnerability there's

00:34:21.030 --> 00:34:24.130
a cost to it an attack and so there has to be

00:34:24.130 --> 00:34:28.050
a value for the target right and when we say

00:34:28.050 --> 00:34:30.630
cute date that's the first date that the you

00:34:30.630 --> 00:34:35.590
know the most motivated attacker is going to

00:34:35.590 --> 00:34:39.130
be able to afford to buy a quantum computer and

00:34:39.130 --> 00:34:43.119
they initially they will not just instantly get

00:34:43.119 --> 00:34:45.559
answers, it will still be multiple days to break.

00:34:46.179 --> 00:34:49.000
So Q date's very real. I don't want to roll back

00:34:49.000 --> 00:34:51.219
any of my statements earlier about how panicked

00:34:51.219 --> 00:34:55.099
we should be. But if you think about that, if

00:34:55.099 --> 00:34:56.980
you have a super expensive quantum computer,

00:34:57.239 --> 00:35:01.320
it still takes you some reasonable amount of

00:35:01.320 --> 00:35:07.019
time to crack a key. If you have a choice of

00:35:07.019 --> 00:35:09.820
targets, you're going to go after CA roots for

00:35:09.820 --> 00:35:14.980
valuable targets. And IoT devices are probably,

00:35:15.159 --> 00:35:17.619
depending on the device, are going to be lower

00:35:17.619 --> 00:35:20.579
down on the threat landscape. And they may have

00:35:20.579 --> 00:35:24.519
a little bit more time to transition. That'll

00:35:24.519 --> 00:35:27.199
be case by case. If it's an IoT device used by

00:35:27.199 --> 00:35:29.980
the military, throw out everything I just said.

00:35:30.559 --> 00:35:34.699
But, you know, if it's like a leak sensor underneath

00:35:34.699 --> 00:35:39.800
your sink, that's... relatively low value uh

00:35:39.800 --> 00:35:43.260
both from an adversary's perspective and what

00:35:43.260 --> 00:35:45.099
they could do with even if they compromise it

00:35:45.099 --> 00:35:48.719
and wanted to go rogue within my home network

00:35:48.719 --> 00:35:53.119
it's still a really weak device um it's not even

00:35:53.119 --> 00:35:57.059
using wi -fi and so um there definitely will

00:35:57.059 --> 00:36:00.199
need to be some triaging and with that particularly

00:36:00.199 --> 00:36:04.670
around the cryptographic trust area where You're

00:36:04.670 --> 00:36:06.510
going to come up with your inventory. You're

00:36:06.510 --> 00:36:09.769
going to look at all the stuff. High value assets,

00:36:10.150 --> 00:36:12.590
you got to transition those first. Some of those,

00:36:12.650 --> 00:36:17.130
it may turn into a monetary risk decision of

00:36:17.130 --> 00:36:20.329
this is super valuable. It's super risky. We

00:36:20.329 --> 00:36:22.730
pay the money, we replace it. And we've created

00:36:22.730 --> 00:36:25.769
e -waste for this one scenario. But there may

00:36:25.769 --> 00:36:28.289
be other scenarios where it's lower risk and

00:36:28.289 --> 00:36:31.510
you can afford to let it play out a little bit.

00:36:32.279 --> 00:36:35.019
So you have to know what's valuable, what's important,

00:36:35.239 --> 00:36:37.840
and especially with that time value. What is

00:36:37.840 --> 00:36:39.480
the stuff that's going to be valuable over 3,

00:36:39.539 --> 00:36:43.179
5, 10, 15, 20 years that still has to stay secret

00:36:43.179 --> 00:36:45.559
or controlled or what have you? Yeah, but to

00:36:45.559 --> 00:36:48.880
Jack's point, the little device monitoring for

00:36:48.880 --> 00:36:52.420
leaks, I mean, that data's not sensitive. It

00:36:52.420 --> 00:36:55.139
really isn't. And let's be honest, if it's a

00:36:55.139 --> 00:36:58.849
small... device out of somewhere. It's probably

00:36:58.849 --> 00:37:00.489
been compromised anyway and the attacker's got

00:37:00.489 --> 00:37:03.949
the keys anyway. I hate to be so cynical. That's

00:37:03.949 --> 00:37:06.050
your red team job coming back. Yeah, exactly.

00:37:06.949 --> 00:37:10.449
And that's why at home here, I mean, all the

00:37:10.449 --> 00:37:12.550
IoT devices are on their own virtual network.

00:37:13.110 --> 00:37:15.150
I don't trust them, man. They don't have access

00:37:15.150 --> 00:37:18.989
to my network. No way. And that's a great point.

00:37:19.030 --> 00:37:20.769
Kind of like with the encryption at rest, there

00:37:20.769 --> 00:37:23.329
can be secondary mitigations that don't rely

00:37:23.329 --> 00:37:26.869
on crypto or that you could isolate the network

00:37:26.869 --> 00:37:30.150
so that you have a device that can speak PQ network

00:37:30.150 --> 00:37:33.630
crypto and it isolates those devices that don't.

00:37:34.130 --> 00:37:38.070
So I think there will be patterns there. can

00:37:38.070 --> 00:37:40.869
be leveraged to protect them. Yeah. And the patterns

00:37:40.869 --> 00:37:42.650
are going to be very similar to, Hey, we have

00:37:42.650 --> 00:37:45.869
this old OT device that's stamped steel and it

00:37:45.869 --> 00:37:48.429
doesn't support crypto at all. So whatever you

00:37:48.429 --> 00:37:51.210
do for that will probably be very similar for,

00:37:51.349 --> 00:37:53.449
Hey, this one's easily compromised. Probably

00:37:53.449 --> 00:37:55.750
the right way to think about it is all of these

00:37:55.750 --> 00:37:58.869
IOT devices that do traditional crypto, just

00:37:58.869 --> 00:38:01.849
assume they don't do crypto anymore and treat

00:38:01.849 --> 00:38:05.679
it that way. So as we're getting close to wrapping

00:38:05.679 --> 00:38:09.980
it up, it sounds like the frame of thinking that

00:38:09.980 --> 00:38:12.380
organizations should have in mind is, hey, we

00:38:12.380 --> 00:38:15.199
need to start now. We need to think about it

00:38:15.199 --> 00:38:18.000
like a special version of a software update thing,

00:38:18.179 --> 00:38:21.320
which sometimes results in isolation because

00:38:21.320 --> 00:38:25.480
there's no way we can update it. And it's really

00:38:25.480 --> 00:38:28.980
very heavy on the TLS, right? And then thinking

00:38:28.980 --> 00:38:33.030
in terms of crypto agility. So, I mean, is that

00:38:33.030 --> 00:38:36.369
sort of the right way to think about it? Yeah,

00:38:36.469 --> 00:38:42.230
I think that's exactly it. I think Michael and

00:38:42.230 --> 00:38:44.329
I are trying to be better in our communications.

00:38:44.369 --> 00:38:46.489
We've been telling customers for years about

00:38:46.489 --> 00:38:51.340
doing a crypto inventory. And Microsoft has been

00:38:51.340 --> 00:38:54.300
through that exercise as well. We're kind of

00:38:54.300 --> 00:38:57.239
coming out of that phase. And so internally,

00:38:57.420 --> 00:38:59.300
we're not talking about that part as much. But

00:38:59.300 --> 00:39:02.159
for a lot of organizations just getting started

00:39:02.159 --> 00:39:05.800
on their journey, they should start with an inventory

00:39:05.800 --> 00:39:08.420
of what are their most valuable assets and what

00:39:08.420 --> 00:39:11.579
is the cryptography protecting it and make sure

00:39:11.579 --> 00:39:13.360
they have a plan there. And let's be honest.

00:39:13.599 --> 00:39:16.059
I mean, the crypto inventory for something like

00:39:16.059 --> 00:39:19.179
Azure is incredibly dynamic. This isn't easy.

00:39:20.159 --> 00:39:23.659
Yes. Yeah. I look at keeping an inventory as

00:39:23.659 --> 00:39:25.400
like keeping a house clean. It's never going

00:39:25.400 --> 00:39:27.519
to be perfect, but you also don't want to be

00:39:27.519 --> 00:39:29.800
in a dirty house. So you got to keep doing the

00:39:29.800 --> 00:39:34.579
work. Yeah. And with your analogy to vulnerability,

00:39:35.039 --> 00:39:37.159
it's a lot of it is scanning. Just because it

00:39:37.159 --> 00:39:39.079
was clean today doesn't mean it'll be clean tomorrow.

00:39:39.239 --> 00:39:43.380
So we rely heavily on network scanning and other

00:39:43.380 --> 00:39:46.599
detections that are automated. So we see things

00:39:46.599 --> 00:39:51.920
coming in. Right. Cool. So can you talk a little

00:39:51.920 --> 00:39:56.179
bit about like which algorithms people should

00:39:56.179 --> 00:39:57.760
be looking for? Like these are the ones that

00:39:57.760 --> 00:40:00.320
are good, validated, blessed, and then kind of

00:40:00.320 --> 00:40:03.400
how's Microsoft approaching it? Yeah. So the

00:40:03.400 --> 00:40:07.190
algorithms I mentioned earlier, CNSA 2 .0. Go

00:40:07.190 --> 00:40:10.269
Google that on the web, pull it up. That's kind

00:40:10.269 --> 00:40:12.869
of my Bible at the moment. Those are the main

00:40:12.869 --> 00:40:14.989
algorithms. And you'll see it actually starts

00:40:14.989 --> 00:40:17.829
off with some familiar faces. To Michael's point

00:40:17.829 --> 00:40:21.369
earlier, symmetric crypto more or less is holding.

00:40:21.690 --> 00:40:27.829
So it's SHA -384, AES -256. You'll notice the

00:40:27.829 --> 00:40:29.929
links are a little bit longer than some previous

00:40:29.929 --> 00:40:32.949
standards. So they did make them longer because

00:40:32.949 --> 00:40:37.239
there are some... accelerations from quantum

00:40:37.239 --> 00:40:39.880
computers, but fundamentally they're holding

00:40:39.880 --> 00:40:45.079
strong. So get a good solid sized key and you

00:40:45.079 --> 00:40:47.880
can keep using those algorithms there. And then

00:40:47.880 --> 00:40:50.860
the new ones that you'll see several of them

00:40:50.860 --> 00:40:52.960
mentioned, my favorite one to talk about because

00:40:52.960 --> 00:40:56.539
it's like the rock star right now is MLChem.

00:40:57.460 --> 00:40:59.900
It's being deployed across the internet right

00:40:59.900 --> 00:41:04.239
now. And it's protecting that key establishment

00:41:04.239 --> 00:41:10.460
in TLS. And it seems to be going well. It's not

00:41:10.460 --> 00:41:15.679
really causing problems. And it's the gold standard

00:41:15.679 --> 00:41:19.699
right now for PQ key exchange or establishment.

00:41:20.300 --> 00:41:23.519
When you get into the signatures. Like Michael

00:41:23.519 --> 00:41:25.460
was mentioning earlier, there's these size issues

00:41:25.460 --> 00:41:28.139
and performance issues, and there's a couple

00:41:28.139 --> 00:41:32.139
of different ones. The MLDSA is kind of MLChem's

00:41:32.139 --> 00:41:36.260
sibling for digital signatures. There's an older

00:41:36.260 --> 00:41:39.380
one called LMS that a lot of hardware vendors

00:41:39.380 --> 00:41:42.519
liked because it was available sooner and they

00:41:42.519 --> 00:41:45.059
could start rolling it into their hardware devices.

00:41:45.639 --> 00:41:48.980
And those are kind of the two signature ones.

00:41:49.199 --> 00:41:54.130
I don't want to... As far as the signature algorithms,

00:41:54.530 --> 00:42:00.030
they work fine. LMS has some issues in that only

00:42:00.030 --> 00:42:02.929
one person can be doing the sign operation at

00:42:02.929 --> 00:42:05.710
a time. So that creates some management issues.

00:42:06.309 --> 00:42:12.300
And MLDSA doesn't have that. behaves on the signing

00:42:12.300 --> 00:42:16.000
side a lot more like RSA and EC. It doesn't have

00:42:16.000 --> 00:42:18.880
the restrictions LMS has. And so we're kind of

00:42:18.880 --> 00:42:20.679
seeing this trade -off in the industry right

00:42:20.679 --> 00:42:24.960
now where a lot of hardware and IoT has added

00:42:24.960 --> 00:42:28.579
support for LMS and all the software people are

00:42:28.579 --> 00:42:33.079
going to MLDSA and probably will, I don't think

00:42:33.079 --> 00:42:35.739
they'll ever consider LMS. There's too much management

00:42:35.739 --> 00:42:39.789
overhead with it. And that is the area that NIST

00:42:39.789 --> 00:42:43.110
is most aggressively continuing to look for alternate

00:42:43.110 --> 00:42:46.389
algorithms. Anything to add there, Michael? Yeah,

00:42:46.429 --> 00:42:48.889
there is another one, which is SLHDSA, right?

00:42:48.949 --> 00:42:52.550
So what's the scoop there? The key word in that

00:42:52.550 --> 00:42:55.989
is stateless hash -based. So do you want to touch

00:42:55.989 --> 00:42:57.769
on that at all? Or is that just going to really

00:42:57.769 --> 00:43:02.309
send us down a rabbit hole? It's another one.

00:43:02.369 --> 00:43:05.710
I think, yeah, I don't have much to say about

00:43:05.710 --> 00:43:12.989
it. Some modules are still implementing it. And

00:43:12.989 --> 00:43:16.449
as I'm not one of the implementers, I'm not sure

00:43:16.449 --> 00:43:19.230
why, but ML DSA seems to have been more popular

00:43:19.230 --> 00:43:21.969
around the implementation. Michael, I know you've

00:43:21.969 --> 00:43:23.630
been looking at some of this. Is there something

00:43:23.630 --> 00:43:25.550
you wanted to share about that? No, not really.

00:43:25.670 --> 00:43:26.769
I just thought I'd throw it out there just for

00:43:26.769 --> 00:43:28.929
completeness. You're probably going to hear ML

00:43:28.929 --> 00:43:33.289
KEM. You're going to hear about the most. Next

00:43:33.289 --> 00:43:37.090
will be MLDSA, and you may hear some SLHDSA.

00:43:37.389 --> 00:43:41.670
The only thing you need to know is that the SLHDSA

00:43:41.670 --> 00:43:46.389
is a lot slower, and it also has much bigger

00:43:46.389 --> 00:43:49.570
signatures. My guess is it will be used for things

00:43:49.570 --> 00:43:52.360
that are going to be extremely long -lived. you

00:43:52.360 --> 00:43:55.880
know, 30 years sort of timeframe. Yeah, exactly.

00:43:56.260 --> 00:43:59.619
Exactly. But, you know, who knows? Anyway, I

00:43:59.619 --> 00:44:02.320
just wanted to just throw out, because people

00:44:02.320 --> 00:44:04.860
are going to see these things. Yep. And it's

00:44:04.860 --> 00:44:08.639
worthwhile. We'll see LMS for hardware devices.

00:44:08.860 --> 00:44:11.860
Okay. I don't mean to badmouth it. Like it is

00:44:11.860 --> 00:44:15.800
NIST approved. It's a solid algorithm. The challenges

00:44:15.800 --> 00:44:18.599
there are on doing the signatures. But if you're

00:44:18.599 --> 00:44:23.250
buying. a component like a TPM or a CPU that

00:44:23.250 --> 00:44:26.550
uses LMS. It's the manufacturer that had to deal

00:44:26.550 --> 00:44:30.030
with that, so you don't care. And you can benefit.

00:44:30.110 --> 00:44:33.050
It is a NIST -approved algorithm and should be

00:44:33.050 --> 00:44:35.230
fine. And you bring up a really interesting point

00:44:35.230 --> 00:44:37.630
there, though, and I really do not want to go

00:44:37.630 --> 00:44:39.769
down this rabbit hole, but I'm going to circle

00:44:39.769 --> 00:44:42.530
around the top of the rabbit hole, and that is

00:44:42.530 --> 00:44:44.710
standards. A lot of the standards are still evolving

00:44:44.710 --> 00:44:47.590
in this area. That's all I'm going to say about

00:44:47.590 --> 00:44:52.380
that. Yes, a huge rabbit hole. They're still

00:44:52.380 --> 00:44:55.400
evolving. And that's why it's easy to point to

00:44:55.400 --> 00:44:58.579
TLS. It's the top risk and the standards are

00:44:58.579 --> 00:45:03.820
relatively solidified and being rolled out. So

00:45:03.820 --> 00:45:06.840
go do that. It's the top risk. It is standardized.

00:45:07.059 --> 00:45:11.659
As you start, look, and at rest mostly uses AES.

00:45:11.659 --> 00:45:14.579
So you're good there. The cryptographic trust,

00:45:14.920 --> 00:45:19.260
the standards. aren't completely finalized. And

00:45:19.260 --> 00:45:23.159
so you're kind of at the stage of get your inventory,

00:45:23.480 --> 00:45:25.760
talk to your vendors, talk to the teams that

00:45:25.760 --> 00:45:30.159
you rely on, your HSM vendors, your PKI providers

00:45:30.159 --> 00:45:32.840
or teams inside your company and start figuring

00:45:32.840 --> 00:45:36.119
out your plan. But know that for cryptographic

00:45:36.119 --> 00:45:39.260
trust, several of those standards are still being

00:45:39.260 --> 00:45:42.199
finalized. So they may not be ready to go do

00:45:42.199 --> 00:45:45.199
something this quarter. But people are moving

00:45:45.199 --> 00:45:48.000
fast now. They see that date coming. It's become

00:45:48.000 --> 00:45:52.300
a lot more real and things are moving fast. So

00:45:52.300 --> 00:45:54.860
I got one last kind of technical question before

00:45:54.860 --> 00:45:58.320
we get into our kind of standard wrap up. What

00:45:58.320 --> 00:46:00.719
is Microsoft doing that folks should be aware

00:46:00.719 --> 00:46:05.420
of in this space? Yeah. So we started our inventory

00:46:05.420 --> 00:46:08.420
a long time ago and identified a lot of our foundational

00:46:08.420 --> 00:46:13.059
components. And if you've been following the

00:46:13.059 --> 00:46:14.500
news, it's kind of buried because it's kind of

00:46:14.500 --> 00:46:17.920
crypto stuff. But our cryptography team that

00:46:17.920 --> 00:46:23.480
actually implements crypto for Windows and Linux

00:46:23.480 --> 00:46:28.340
and other products, they've been delivering their

00:46:28.340 --> 00:46:31.480
crypto module, SimCrypt, adding these new algorithms.

00:46:32.159 --> 00:46:35.420
at a really regular cadence. So they're all out

00:46:35.420 --> 00:46:39.039
there and they're continuously making new announcements.

00:46:39.280 --> 00:46:43.860
They're very much up to speed. So that's been

00:46:43.860 --> 00:46:46.719
a big investment. And what you're going to start

00:46:46.719 --> 00:46:51.219
seeing coming out next is, well, we already support

00:46:51.219 --> 00:46:53.539
TLS 1 .3. That's been out there for a long time,

00:46:53.599 --> 00:46:55.820
but we'll start integrating these algorithms

00:46:55.820 --> 00:46:57.719
into our products and you'll see those coming

00:46:57.719 --> 00:47:03.019
out very quickly here. And that's kind of a sign

00:47:03.019 --> 00:47:07.059
we're transitioning from the inventory and solve

00:47:07.059 --> 00:47:12.840
your kind of core component issues to deploying

00:47:12.840 --> 00:47:15.760
and rolling it out so that we're using it internally

00:47:15.760 --> 00:47:18.840
and customers can adopt it. And that's what we'll

00:47:18.840 --> 00:47:21.059
be busy doing over the next couple of years,

00:47:21.219 --> 00:47:24.119
trying to give our customers enough time so they

00:47:24.119 --> 00:47:26.539
can go through that transition themselves. Because

00:47:26.539 --> 00:47:29.739
almost all of this, there's... So it's not exactly

00:47:29.739 --> 00:47:31.519
client -server, but there's kind of producer

00:47:31.519 --> 00:47:34.699
-consumer model, right? We have to make it available.

00:47:34.860 --> 00:47:36.900
Our endpoints have to support it. Our clients

00:47:36.900 --> 00:47:39.360
need to support it. And then the customers can

00:47:39.360 --> 00:47:42.380
go rotate their routes, rotate their keys, and

00:47:42.380 --> 00:47:45.940
adopt it. Yeah, and just to add to that, so it

00:47:45.940 --> 00:47:48.320
really is very much a layered approach, right?

00:47:48.380 --> 00:47:50.139
So we've got SimCrypt essentially down the bottom,

00:47:50.199 --> 00:47:52.420
which is the actual low -level algorithms. By

00:47:52.420 --> 00:47:54.559
the way, that code is up on GitHub if anyone

00:47:54.559 --> 00:47:59.380
wants to look at it. the post -quantum algorithms

00:47:59.380 --> 00:48:02.159
into .NET, and they just call out to SimCrypt

00:48:02.159 --> 00:48:04.800
so you can do it nice and easily in .NET. Then

00:48:04.800 --> 00:48:07.420
the next layer kind of above that would be the

00:48:07.420 --> 00:48:10.679
likes of TLS, which would then also consume SimCrypt

00:48:10.679 --> 00:48:14.179
to provide the asymmetric, sorry, the post -quantum

00:48:14.179 --> 00:48:18.980
algorithms in TLS 1 .3. We will have a version

00:48:18.980 --> 00:48:21.199
of S -Channel, so in Windows, the code that does

00:48:21.199 --> 00:48:23.639
that is called S -Channel, and we will have that

00:48:23.639 --> 00:48:26.860
out very soon with post -quantum algorithms.

00:48:27.879 --> 00:48:29.559
built -in as well, so you can go and kick the

00:48:29.559 --> 00:48:31.980
tires on it. And then you'll see other products

00:48:31.980 --> 00:48:33.579
with data at rest and so on, but the big one

00:48:33.579 --> 00:48:36.019
by far is TLS 1 .3 with post -quantum algorithms.

00:48:36.719 --> 00:48:39.019
I'm going to wrap it up with two questions. The

00:48:39.019 --> 00:48:42.239
first is for both of y 'all. What's a day in

00:48:42.239 --> 00:48:44.820
the life? So Jack, if you can kind of give us

00:48:44.820 --> 00:48:47.800
a sense of what is life like in the midst of

00:48:47.800 --> 00:48:52.340
this command center? Well, I start every day

00:48:52.340 --> 00:48:55.360
with a good workout before I open up my phone

00:48:55.360 --> 00:48:58.659
and start looking at the day's fire drills. So

00:48:58.659 --> 00:49:01.840
I get my workout in, say my prayers, and then

00:49:01.840 --> 00:49:06.599
open up email and chat. A lot of my days, because

00:49:06.599 --> 00:49:09.039
I'm still running the key management team, so

00:49:09.039 --> 00:49:12.619
a lot of my day is split between on the post

00:49:12.619 --> 00:49:16.760
-quantum side, meeting with the experts and teams

00:49:16.760 --> 00:49:20.429
around Microsoft. Bringing them up to speed on

00:49:20.429 --> 00:49:22.829
what I'm seeing, learning from them about the

00:49:22.829 --> 00:49:25.849
challenges they're seeing and working to find

00:49:25.849 --> 00:49:28.630
solutions. And a big part of that is we're leveraging.

00:49:29.010 --> 00:49:31.610
We're now kind of transitioning from building

00:49:31.610 --> 00:49:35.150
components to rolling it out. And so we're kind

00:49:35.150 --> 00:49:37.869
of transforming all of these crypto transitions,

00:49:38.130 --> 00:49:41.750
kind of like long patching into KPIs that we

00:49:41.750 --> 00:49:45.170
can just go drive from zero to 100 percent. And,

00:49:45.170 --> 00:49:48.969
you know. Forming those KPIs, getting teams to

00:49:48.969 --> 00:49:53.449
own them, and helping people, the DCSOs, properly

00:49:53.449 --> 00:49:57.570
understand the risk for each of these KPIs. Because

00:49:57.570 --> 00:49:59.469
they are different, as we discussed, for TLS

00:49:59.469 --> 00:50:03.030
versus encryption at rest and cryptographic trust

00:50:03.030 --> 00:50:05.730
and getting the appropriate level of urgency.

00:50:06.090 --> 00:50:09.050
Because for the consuming teams, they have to

00:50:09.050 --> 00:50:12.050
consume this work alongside existing vulnerabilities,

00:50:12.349 --> 00:50:15.510
existing security issues. We want to make sure

00:50:15.510 --> 00:50:18.670
the risk is appropriately understood and not

00:50:18.670 --> 00:50:21.170
oversold because we don't want them wasting effort

00:50:21.170 --> 00:50:24.989
if there's something else more urgent. So it's

00:50:24.989 --> 00:50:27.130
a lot of those discussions, writing, working

00:50:27.130 --> 00:50:30.010
with Michael, trying to get communications for

00:50:30.010 --> 00:50:32.710
internal and external consumption on what people

00:50:32.710 --> 00:50:36.409
need to go and do. And then all the fun stuff

00:50:36.409 --> 00:50:39.750
I get to do around key management with HSMs.

00:50:41.269 --> 00:50:44.349
cloud computing there and sovereignty. We've

00:50:44.349 --> 00:50:47.010
been talking about external key management. That's

00:50:47.010 --> 00:50:49.550
a fun new feature. We could talk about that sometime

00:50:49.550 --> 00:50:52.309
too. So just going back and forth between the

00:50:52.309 --> 00:50:55.110
two and trying to stay happy and positive and

00:50:55.110 --> 00:50:57.909
get home to my family at the end of the day.

00:50:58.789 --> 00:51:00.869
I tend to actually do my workouts in the middle

00:51:00.869 --> 00:51:03.269
of the day around lunchtime. I wish I could do

00:51:03.269 --> 00:51:04.909
them in the morning. My wife wants me to do them

00:51:04.909 --> 00:51:07.590
in the morning, but that's another discussion

00:51:07.590 --> 00:51:10.519
for another day. So my day starts, actually a

00:51:10.519 --> 00:51:12.320
bit of a joke really, is I make coffee for both

00:51:12.320 --> 00:51:14.019
my wife and I. And it's actually kind of a bit

00:51:14.019 --> 00:51:16.000
of a laugh because if I'm not around and she

00:51:16.000 --> 00:51:17.559
has to make her own coffee, she complains about

00:51:17.559 --> 00:51:20.739
it. And it makes me aware, you know, rubs it

00:51:20.739 --> 00:51:22.159
in for the rest of it. I had to make my own coffee

00:51:22.159 --> 00:51:24.559
this morning. And a big one I do because I'm

00:51:24.559 --> 00:51:26.900
two hours ahead of Redmond. There's sometimes

00:51:26.900 --> 00:51:29.670
there's stuff that's coming overnight. Earlier

00:51:29.670 --> 00:51:33.829
this week, and I really am telling tales outside

00:51:33.829 --> 00:51:35.409
of the playground here, Jack, but there was a

00:51:35.409 --> 00:51:38.190
message earlier this week from Jack saying, hey,

00:51:38.250 --> 00:51:40.210
when you wake up tomorrow, you need to work on

00:51:40.210 --> 00:51:43.769
this one thing, which I did. But yeah, a big

00:51:43.769 --> 00:51:46.849
part of what I'm looking at is, so the buzzword

00:51:46.849 --> 00:51:48.809
right now inside Microsoft is reducing toil.

00:51:49.610 --> 00:51:52.050
A lot of security stuff is just hard. It's just

00:51:52.050 --> 00:51:53.840
a lot of... toil. It's stuff that you've just

00:51:53.840 --> 00:51:56.119
got to do because it's the right thing to do.

00:51:56.500 --> 00:51:58.679
So we are working out how can we come up with

00:51:58.679 --> 00:52:01.199
appropriate guidance, really prescriptive guidance,

00:52:01.320 --> 00:52:07.219
but also using AI to help make the impedance

00:52:07.219 --> 00:52:10.460
a lot lower, sort of reducing that resistance.

00:52:11.019 --> 00:52:13.320
And so a lot of work I'm doing in that area with

00:52:13.320 --> 00:52:16.039
the crypto board at Microsoft. I think that's

00:52:16.039 --> 00:52:18.079
really important. In fact, I think if anyone

00:52:18.079 --> 00:52:20.739
is not doing that, they really should be doing

00:52:20.739 --> 00:52:22.820
it. Something else I left out is for me to bring

00:52:22.820 --> 00:52:24.699
it up. Jack, I said a little prayer over my wife

00:52:24.699 --> 00:52:27.780
every morning. Yeah. And then a lot of it is,

00:52:27.780 --> 00:52:29.659
is email and correspondence and talking to product

00:52:29.659 --> 00:52:31.659
groups, but also talking to customers. A lot

00:52:31.659 --> 00:52:33.840
of customers, this sounds like a horrible thing.

00:52:33.900 --> 00:52:36.059
I don't mean it, but just have no idea what to

00:52:36.059 --> 00:52:38.219
do. I don't mean it in a horrible way. And they're

00:52:38.219 --> 00:52:40.539
really looking to us for guidance and help. And

00:52:40.539 --> 00:52:42.119
so a big part of what I'm doing is not just working

00:52:42.119 --> 00:52:44.300
with our first party customers, like, you know,

00:52:44.900 --> 00:52:46.599
storage, Azure data. I'm spending a lot of time

00:52:46.599 --> 00:52:49.019
now with the Azure data team, in part because

00:52:49.019 --> 00:52:51.440
I think they have a reasonable story moving forward,

00:52:51.500 --> 00:52:53.840
but there's some areas that need real work. And

00:52:53.840 --> 00:52:57.599
then also working with customers as well. A lot

00:52:57.599 --> 00:52:59.820
of them seem to have come from finance and governments.

00:53:00.860 --> 00:53:04.739
It seems to be a common pattern. So no day is

00:53:04.739 --> 00:53:07.039
the same, ever. I still get a couple of pings

00:53:07.039 --> 00:53:08.739
from the red team once in a while, but that'll

00:53:08.739 --> 00:53:12.699
end up stopping at some point. Every day is totally

00:53:12.699 --> 00:53:17.360
different. So, Jack, final thoughts. Anything

00:53:17.360 --> 00:53:19.900
you'd like to leave our audience with as sort

00:53:19.900 --> 00:53:22.440
of the most important thing to sort of remember

00:53:22.440 --> 00:53:25.360
and take away? I think I've definitely seen what

00:53:25.360 --> 00:53:27.179
Michael just mentioned there about the feeling

00:53:27.179 --> 00:53:30.440
of overwhelmed. And I think some of the analogies

00:53:30.440 --> 00:53:32.739
you shared and just kind of breaking down the

00:53:32.739 --> 00:53:36.840
problem into segments like your network communications

00:53:36.840 --> 00:53:40.840
and TLS and others, I think are super helpful.

00:53:42.579 --> 00:53:45.860
People pretty quickly get the urgency and then

00:53:45.860 --> 00:53:48.360
they quickly get overwhelmed because they start

00:53:48.360 --> 00:53:50.380
looking around and they realize we use crypto

00:53:50.380 --> 00:53:52.940
everywhere throughout all of our products, everything

00:53:52.940 --> 00:53:56.940
we're doing. And that can be overwhelming. And

00:53:56.940 --> 00:53:59.280
it's just kind of pause, take a breath, break

00:53:59.280 --> 00:54:02.980
it down, look at TLS. Your encryption at rest

00:54:02.980 --> 00:54:06.099
is probably already. fine, just double check.

00:54:06.340 --> 00:54:09.480
And then once you do that, you're like two thirds

00:54:09.480 --> 00:54:11.960
of the way through the problem. And so then in

00:54:11.960 --> 00:54:14.340
that last area, it's yeah, start getting the

00:54:14.340 --> 00:54:16.840
inventory, but the standards are still coming.

00:54:16.900 --> 00:54:21.489
So, so just be ready. And it's. I think we can

00:54:21.489 --> 00:54:24.769
do this much like Y2K. Hopefully, you know, five

00:54:24.769 --> 00:54:26.510
years from now, we're sitting the other side

00:54:26.510 --> 00:54:28.849
of the transition and quantum computers are here

00:54:28.849 --> 00:54:31.130
and we're looking back and like, yeah, it could

00:54:31.130 --> 00:54:33.750
have been really bad, but the industry rallied

00:54:33.750 --> 00:54:36.750
together, just worked the problem and we got

00:54:36.750 --> 00:54:40.159
out the other side and it's okay. So thank you

00:54:40.159 --> 00:54:43.039
so much for joining us. And Michael, thank you

00:54:43.039 --> 00:54:46.039
for being a guest on the podcast you started

00:54:46.039 --> 00:54:50.139
with us. And with that, we're going to wrap up.

00:54:50.300 --> 00:54:52.400
And thank you all for listening. And we will

00:54:52.400 --> 00:55:09.119
catch you next time. Stay safe out there. Background

00:55:09.119 --> 00:55:12.679
music is from ccmixter .com and licensed under

00:55:12.679 --> 00:55:14.199
the Creative Commons License.