Post-Quantum Crypto with Michael Howard

0:01Speaker 1:How'd you like to listen to. NET Rocks with no ads? Easy. Become a patron. For just $ 5 a month, you get access to a private RSS feed where all the shows have no ads. $ 20 a month will get you that and a special. NET Rocks patron mug. Sign up now at patreon.dotnetrocks.com. NET Rocks Hey, and welcome back to. NET Rocks. I'm Carl Franklin. And I'm Richard Campbell. And Michael Howard's here with us. We'll have him jump in if he wants to in the beginning. And we'll introduce him a little bit later after the first bits. You know what those are. Here we go. Here we go. 2020.

0:49Speaker 2:It's episode 20 when we're almost done, right? Like this ends in 20 after 2026. So we got like six more of these.

0:57Speaker 1:And it's becoming less and less interesting because most people have lived through the last six years.

1:01Speaker 2:It's so current. Yeah. It's kind of now. Especially 2020, because of course, what can you talk about except COVID?

1:08Speaker 1:Oh my God, COVID. All right, I'm done, Richard. What about space? Yeah, thanks for playing, guys.

1:13Speaker 2:Well, the other thing I would talk about is this is when the UK officially leaves.

1:18Speaker 1:The EU. Oh, there's more news, but COVID is the big one. George Floyd. It is the big one, yeah. George Floyd killed. Big, big reaction to that that sparked off a lot of stuff. Joe Biden beat Donald Trump. Yes, there, I said it because that's the truth. Worldwide economic collapse caused by COVID. Lockdowns. Yeah, it's just stall. It was just horrible. Donald Trump was impeached for the first time. Oh, in the first year. I was at the end. A lot of wildfires in Australia and Western US. The terrible ones.

1:55Speaker 2:Know about and now and today it's really relevant in september the second nagorno-karabakh war so this is between azerbaijan and armenia this is an enclave that normally is controlled by armenia but the azerbaijanis wanted it and they attack and so the azerbaijanis are the ones with the oil money and they're muslim the uh the armenians are predominantly christian uh the azerbaijanis attack and to be clear this is a very complicated conflict like it's gone on literally for centuries But it was a drone war. It was arguably the first drone war.

2:29Speaker 1:Wow.

2:29Speaker 2:The Azerbaijanis bought Turkish Bayraktar drones. They had bought some of the surveillance equipment from the Israelis. And so they had continuous surveillance. They were using drones for attack. They destroyed missile sites and so forth. The Iranians were fighting the old style with Soviet equipment. and just kind of got rolled over. Like you'd think the Russians would have taken a hint watching their stuff be torn up by drones in 2020. Instead, they bought a lot of drones. Well, they did eventually, but first they got hit pretty hard. Anyway, it was only six weeks. And that doesn't change the fact that a lot of people died. It did result in the fall of the, of the region and the change in the, in the environment over there. But it's just a precursor conflict to, to, you know, we saw an example, just of course it was COVID and, There was all the things going on at that time in that year that nobody was paying attention to.

3:25Speaker 3:Yeah.

3:25Speaker 1:A couple other notable deaths in 2020. Ruth Bader Ginsburg. What a blunder.

3:32Speaker 3:Yeah.

3:33Speaker 1:Kobe Bryant. Yeah, the helicopter accident. And good trouble himself, John Lewis.

3:38Speaker 3:Right.

3:39Speaker 1:Died civil rights icon. Yeah. Yeah, it was just a bad- Tough year. Bad years. Tough year.

3:44Speaker 2:Yeah. Do you want to know what happened in space? There wasn't a ton, but there's some important ones. In February, Solar Orbiter launches. You don't really know much about this one. This was a joint ESA-NASA mission in that order. It's very much a European mission with NASA instrumentations and They provided the Atlas V as well, but it was built by Airbus. And its goal was to get a view of the poles of the sun. Normally, you're launching your spacecraft because the Earth's in the plane of the ecliptic.

4:10Speaker 2:Your spacecraft are going to be as well. Trying to get to high inclination is very, very difficult. Not that they got all that high. They'll fly down into a looping orbit inside the orbit of Mercury and then use Venus to do the slingshots and repeatedly tip the spacecraft. So it is about 24 degrees off the planet ecliptic. It takes a ton of energy to do that. They borrowed lots of energy from Venus, but it's a one-ton spacecraft, so it.

4:34Speaker 1:Can do that.

4:35Speaker 2:But it'll get us our first visual views of the poles of the sun.

4:39Speaker 1:Cool mission. Yeah, that is cool.

4:41Speaker 2:In May. the first crew dragon demo mission. So this was Bob, uh, Benneken and Doug Hurley go up to the space station and demonstrate that, uh, the commercial spacecraft can actually go to the space station properly. And that'll be followed up in November with a regular crew flight of four astronauts to crew the space station.

4:59Speaker 1:So there you go.

5:01Speaker 2:After what this would be nine years since the Atlantis had landed. And the only support for the station was, uh, Via Soyuz, now the Americans had a vehicle again, the former crew driver.

5:11Speaker 1:I got a question, which Michael might know the answer to, but you said ESA and NASA did this thing together in 2020, but Brexit was in 2020. Was Was Britain part of ESA in 2020? Did they participate?

5:25Speaker 3:Yeah, I don't think so. I could be wrong, but I don't think so.

5:28Speaker 2:It's mostly Germany, France.

5:29Speaker 4:Yeah.

5:29Speaker 1:Okay. It's Airbus, it's Defense of the Space. All right.

5:32Speaker 2:July, the Perseverance rover. So, this was the test article for the original Curiosity rover with a bunch of upgraded things, better wheels, better suspension.

5:41Speaker 3:Yeah.

5:42Speaker 2:New instruments, the Ingenuity helicopter, all of that stuff gets launched in July. July is the perfect time to launch to Mars, July 2020. There's a synchronicity to the orbits, right? They're in a two, three period. And so every roughly two years, you get a chance to do a bunch of flights. And so July, there's actually three. There's the Perseverance rover, which is huge. There's also China's very first mission to Mars, Tianwen-1. And then the UAE. the United Aramids launches their Hope climate orbiter to Mars. So three launches in the same month. Wow.

6:15Speaker 3:Did they all make it?

6:16Speaker 2:In October.

6:17Speaker 3:The U.S. made it.

6:18Speaker 2:They all make it.

6:19Speaker 1:Yeah, actually. Very cool.

6:20Speaker 2:And I mean, I'll talk more about the Tianwen-1 when it lands next year. So in episode 2021. Because that was China's first attempt to go to Mars and it fully worked. Nobody's pulled that off before. Everybody loses a few trying to get to Mars.

6:35Speaker 1:Just name it. Everybody does. But China didn't.

6:38Speaker 2:But, you know, the advantage of being, I don't know, fourth or fifth mover or something like that. In October, OSIRIS-REx, one of the asteroid missions, touches on asteroid Bennu. and collects a sample there. In fact, it does a little too well because when it touches, Bennu is very much a rubble pile and all that gravel goes everywhere and they actually have trouble closing up the sample container because there's too much stuff. They have to come up with such technical maneuvers as shaking a little off to try and get the thing closed up so they can put it in the capsule to return. Another asteroid mission at the end of the year in December, Hayabusa 2, will actually successfully return It's sample payload from the asteroid Regu, and that is a JAXA mission. A little recap on what SpaceX did in 2020. There was actually 25 launches from SpaceX, which at the time was an amazing number.

7:29Speaker 2:Just remembering that SpaceX will do 150 this year. So obviously, there's the two Crew Dragons, the test run in March, and then the full payload in November. They'll also fly 14 Starlink missions, 833 satellites for a network of almost 900 by the end of the year.

7:47Speaker 4:Wow.

7:47Speaker 3:Have you ever seen the Starlink satellites leaving the spaceship? Yeah. It's like pizza boxes going out.

7:52Speaker 2:Yeah, yeah. Well, now they've gotten bigger because of the V2 minis. And so, they only fly like 24 or 28 of them depending on the inclination. But at this time, they're flying 60 a run.

8:03Speaker 1:That's crazy. Wow.

8:04Speaker 2:Just these huge numbers of satellites. And that's where they also, this is the year where they have the reflectivity problems. And so you can see them for an extended period of time until they learn how to orient them and paint them correctly so they're not so visible and don't bother people so much.

8:19Speaker 1:I remember there was a bunch of astronomers that were complaining they were polluting the night sky with their telescopes.

8:24Speaker 2:Yeah. Well, and that's still an issue, although let's face it, digital processing can fix that.

8:28Speaker 1:Right.

8:29Speaker 2:But making bright lights make it worse. So making sure it doesn't reflect sunlight helps.

8:34Speaker 1:I've seen them though. I've seen the trail go across and it's pretty fascinating and a little bit I don't know. You know, SpaceX does some things that if you weren't paying attention, you'd think we're being invaded by aliens.

8:45Speaker 2:Well, or, you know, or Dr. No is in full swing. Like the line between supervillain and tech billionaire is getting very narrow.

8:53Speaker 1:Just people don't know. Like, you know, the first time that I saw the booster rocket spinning, you know, when it– I thought it was like a spaceship. And so did a million other people until I found out, oh, that's just SpaceX. That's what they do. And what are those lights going? Hey, is that Santa Claus? No, that's just SpaceX.

9:09Speaker 3:Yeah. I use Stellarium and it'll show you all the SpaceX.

9:14Speaker 1:Sure. Something's whizzing around out there. I know. Must be my Facebook friends. They're at average intelligence or ability to look things up.

9:22Speaker 2:10,000 plus of them by the end of this year, just so you know. There'll be a bunch of other missions as well, including a couple of GPS satellites. They'll also start doing their Starship flights, the hop tests, and the first, what they called belly flop test, where they fire it up to a few kilometers up and then let it fall on its belly so they could actually land it. That was SN8 by the end of 2020. It does not go well, but they'll solve that and prove that this whole idea is even possible. All right, should we move on to computing?

9:47Speaker 3:Yeah.

9:47Speaker 2:We'll start in January with the OpenAI paper called the Neural Scaling Laws. Lead author is Jared Kaplan. There's a whole bunch of others, including Daryl Modi, who this time is at OpenAI, will eventually be the CEO of Anthrop. And this was the paper that sort of kicked off this idea of, you know, different from all the other machine learning models we did where we worry about overfitting and training sets and so forth. that for large language models, we should just train on as much data as we can possibly get. There's lots of debate as to whether this is that good an idea. We've definitely come into other techniques from there. But this paper is kind of the stimulus for what will be the insanity coming in the next couple of years. January is also when Microsoft switches over to Chromium as the rendering engine in the new Edge browser. The pandemic's in full swing in March is when lockdowns really kick off and everybody goes home and everybody's got Zoom. Teams explodes for better or worse.

10:42Speaker 2:But a little thing I paid attention to was Terry Breton, who is the EU Internal Market Commissioner. reached out to Netflix and YouTube and Amazon Prime and asked him to turn off all the 4K features. He was concerned about the amount of available bandwidth across Europe as everybody went home and used the internet differently. Was it actually a crisis? Nobody knows for sure, or at least he's not talking about it. They started turning up the bandwidth again in May, and Netflix's Posts about this are interesting because they talk about network changes and increasing capacity and things like that.

11:24Speaker 2:So maybe there really was a crisis because of the change in the Internet consumption due to COVID. But, you know, a lot of details aren't revealed necessarily. But that to me was very interesting.

11:33Speaker 1:Yeah.

11:34Speaker 2:April is when Uncle Satchit says, two years worth of digital transformation in two months. Because everybody had to all work. This is when I started doing True Run As a week, just talking about topics around what was necessary for sysadmins with everybody working from home.

11:53Speaker 1:My brother is a programmer at a local company. He's been there for years and years. And they basically do online vehicle registrations. And they were the first in the area to do it. And their customers are states, not individual sales places, dealerships. But anyway, they were renting an office building in an office park out here, umpteen billion square feet. And during COVID, people went to work at home. And I just remember Jay coming to rehearsal once and said, Well, I've resigned myself to the idea that I'm never going back to the office. And they basically moved out of the office. Yeah, lots did. They stopped renting it. And I think, in general, office space took a big dive in 2020.

12:39Speaker 2:You think about all the property that Microsoft gave up in Bellevue.

12:43Speaker 1:Yeah.

12:43Speaker 2:They kept their buildings in Redmond, but all that rented space.

12:46Speaker 1:In Bellevue went away.

12:47Speaker 3:Right.

12:47Speaker 1:And all of it went to Zoom.

12:48Speaker 3:Yeah.

12:49Speaker 1:Well, to Teams.

12:50Speaker 2:Teams. The first virtual build in May is also when they do the full release of Blazor WebAssembly.

12:59Speaker 1:Yeah.

13:00Speaker 2:Obviously, a bunch of other cool announcements around building that time span. Of course, Blazor, not the first WA programming language, Golang added WA support back in 2018. In June, and again, no people remember much about this because it was mid-pandemic. Microsoft is a big splash about OpenAI GPT-3 being built on what they called the Azure supercomputer, which was a bunch of different Azure data centers harnessed together with 10,000 GPUs, 285,000 CPUs.

13:28Speaker 2:cpu cores to build a get this 175 billion parameter model wow i mean big big big for the time not so much anymore but at the time.

13:38Speaker 1:I remember uh brian mckay who's one of my happy next guys getting on slack and telling us how awesome this gpt thing was but it was difficult to set up at the time but then yeah you know i tried it and of course like everybody else was kind of blown away.

13:52Speaker 2:Yeah Later that year in September is when Microsoft actually licenses GPT-3 from OpenAI, which I presume is how GitHub gets access to it. They'll make GitHub Copilot the following. A couple more stories. In November, Apple announces the M1 processor.

14:08Speaker 1:Yes.

14:09Speaker 2:And I mention this because this, I would argue, is Tim Cook's most memorable move. He was always a hardware guy. This is an astonishing piece of hardware. There's a system on a chip where the GPU and CPU, NPU, the IO and security buses and so forth are all literally in the same die. The memory is in the same package. So this is made by TSMC, five nanometer process, about 16 billion transistors total. That includes eight CPU cores, eight GPU cores, a 16 core neural engine, and up to 16 gigabytes of RAM right.

14:42Speaker 1:On the package.

14:43Speaker 2:So you get both lower power consumption and higher performance. And little would we realize.

14:48Speaker 1:I have a MacBook Pro with an M1. Yeah. First gen. And it's good.

14:52Speaker 3:Is that 16? Is that megabytes or gigabytes?

14:54Speaker 1:Gigs.

14:55Speaker 3:Yeah. That's RAM, RAM, not cache.

14:57Speaker 2:That's RAM, RAM.

14:58Speaker 3:Okay. Yeah.

14:58Speaker 2:They're not putting cache on. The cache is there too.

15:01Speaker 1:Okay.

15:01Speaker 2:And also that RAM is shared with the GPU.

15:03Speaker 1:Right.

15:04Speaker 2:So what we're doing right now with LLMs and the new agent models and so forth, The M1 was built for it, not knowing it was built for it. They were just trying to make the most efficient computer they could consume the least power. And this is Apple's move back to ARM, having come from the Motorola chipset, moved to Intel for a few years. Now they're making their own thing based on ARM.

15:26Speaker 1:Two more.

15:26Speaker 2:December, both in December. The SolarWinds supply chain attack. So this is Russian SVR. The pure brilliance of this is unbelievable. So in September of 2019, hackers successfully break into the SolarWinds development environment and they insert code into the development chain. The way they do it is incredibly insidious. It's part of their build system that they replace code in the build without actually changing the visible source code. So developers don't think their code has changed at all, but what they're actually compiling is different code with this thing called the sunburst backdoor. They, they, they, It takes them a few months of doing testing to get this to work.

16:03Speaker 2:By March, they have actually figured it out. And the Orion monitoring software, SolarWinds builds this infrastructure monitoring software, is now distributed to 18,000 customers with the Sunburst backdoor in it. The Russians are successful enough that in June, they actually removed the whole build injection system. Like, they're done. And are happily operating it. Now, admittedly, they don't actually use that backdoor much. Maybe 100 customers are totally affected. But it's in December when one of those customers, a security company called FireEye, realizes they've been exploited and traces it back to the Orion code base and basically pops the whole thing open. It's an incredibly sophisticated supply chain attack and scares just not actually everybody. It's not the first one, but in a lot of ways, it's the one that made the most news.

16:48Speaker 1:It could be made into a feature film, actually, if it was handled correctly.

16:52Speaker 2:It's astonishing.

16:53Speaker 1:Yeah.

16:55Speaker 2:And if the Russians hadn't decided to go after FireEye, who knows when it would have been detected. Just he went after the guys who were in the security space and good enough at attacking breach properly.

17:05Speaker 3:Yeah, I remember when I was invited to a meeting to be briefed on the attack when we sort of knew what was going on. And yeah, I'll be frank, I was kind of gobsmacked actually by- Gobsmacked, yeah. By the sophistication.

17:18Speaker 2:It's so clever. Holy man. I don't expect bad guys to be this smart, right? If they were smart, they'd be good guys. Like the idea that bad guys would come up with something this clever. But again, state actors, like they're working for more than just a paycheck here.

17:32Speaker 3:Yeah, but remember though, you know, As Sherrod Dugripo has told me many, many times, this is their day job, right? They come to work, they clock in, they do the work, they have reviews every year, they go home to their families, and they start again tomorrow.

17:46Speaker 2:They get promotions by figuring this stuff out.

17:48Speaker 3:Exactly. It's just their job.

17:49Speaker 1:Yeah. As Dwayne LaFleur would say, oh, this is awesome, guys. This is awesome. It's a stunner.

17:56Speaker 2:I'll finish out the year of compute in 2020 with China's Zhuheng Photonic Quantum Computer, which I think is particularly relevant for today's conversation. This was a dedicated machine using photonic quantum entanglement, which is very, very clever, unique, very different from Sycamore, the Google's device from the previous year, which was the … The hanging chandelier in liquid helium, this doesn't need any of this, but it was built specifically for Gaussian boson sampling.

18:24Speaker 1:Nobody knows what you're talking about, Richard. I'm okay with that. I might contest.

18:29Speaker 3:I mean, I know enough to be dangerous. Talk to me about the software side of it.

18:33Speaker 2:Yeah, and that's the whole thing is this is nowhere near a general purpose computer or even a supercomputer. This is a machine to demonstrate that quantum entanglement can tackle one kind of problem, the Gaussian boson sample problem. Now, that's an important problem, but it was sort of a proof point I think very much this is a, hey, we get to play too. And I think everybody reacted to it that way. Because this 200-second run for something that in theory would have taken this supercomputer 2 billion years, not that anybody's going to test that, it just put China instantly on the map and really made it very clear.

19:05Speaker 2:There's more than one way to quantum. And this is a wildly different way. Not that we've heard much from them since. But in 2020, that was a really big deal.

19:13Speaker 3:But does it run Doom?

19:14Speaker 2:It really doesn't.

19:15Speaker 1:No, not a bit. No, it won't.

19:18Speaker 2:I mean, supercomputers are limited in their own way, too, as well. But this was literally built for one thing. This is like Turing's device for cracking Enigma. Good for one thing. The idea of general-purpose computing is a much different idea than what we're doing in this kind of class of work.

19:34Speaker 1:Anyway.

19:34Speaker 3:Yeah, 100%. I think people need to understand that. Yeah, still people don't grapple that. There won't be an office for quantum. It's not going to exist.

19:43Speaker 1:Oh, man.

19:44Speaker 3:I'm sorry.

19:45Speaker 1:You sold me that subscription. Let's get them on the phone. Yeah.

19:51Speaker 2:And as much as we can tell at this time, these will always be supercomputers for particular problem spaces. Most of them very deterministic problem spaces, too. But let's wrap up the history lesson and get on to our larger conversation about quantum.

20:05Speaker 1:Well, but first, we have to do.

20:08Speaker 2:But first.

20:08Speaker 1:Better know a framework. Roll the music. Awesome.

20:10Speaker 3:All right, man.

20:15Speaker 4:What do you got?

20:19Speaker 1:All right. So, as people who listen to me on my various podcasts and stuff probably know, I bought this big GPU machine. a year or so ago, just because I anticipated being able to run local models.

20:35Speaker 2:And you got it ahead of the hardware crisis too. So how smart are you?

20:38Speaker 3:Yeah.

20:40Speaker 1:I got it at walmart.com for $ 6, 000. It uses an NVIDIA RTX 1590 with 32 gigs of VRAM.

20:49Speaker 2:Today that card's 15 grand if you can find one.

20:52Speaker 1:I have, yeah, now it is. I have 96 gigs of system RAM and it's You know, blinky lights and quiet as anything, right? Which is amazing. So on Coded with AI, Jeff Fritz and I did a series on taking a whole bunch of models that would run on Ollama and running them and then putting it through a test. Basically, a lot of them failed. More so because of context, I think, than this is what I'm learning now, the context size, if it's too small. We'll just barf. The LLM will just and lose it or get into an infinite loop. And basically what I came down to is running llama.cpp. And llama.cpp is like Ollama, but it's not.

21:46Speaker 1:It's a different thing. It's open source. But I can run the fairly new QEN 3.8.27b model and llama cpp will use vram and system ram at the same time and it will balance them out and figure out automatically how much of which to use and let me tell you something this is i this is what i've been waiting for it works so well that i don't feel the need to go back for what i do you know debugging coding all of that stuff i don't need to go back to any frontier models anymore.

22:27Speaker 3:Right.

22:28Speaker 1:I haven't found, I've been using it for a couple of weeks.

22:30Speaker 2:You're just working local now.

22:31Speaker 1:I'm just working local. Yeah. And the only thing I'm that's costing me is electricity. But I got solar panels. There you go. Some pretty good, especially in the summer.

22:39Speaker 2:Feeling good. And that machine you bought, like to build that machine today, it's a big bucks.

22:44Speaker 3:Yeah.

22:44Speaker 1:So you did the right thing. Well, I thought it was big bucks back then, but now... Yeah, it was. Yeah.

22:48Speaker 2:It was a lot of money for a PC back then. It doesn't seem that way at this moment.

22:52Speaker 3:Well, anyway... And what sort of performance are you getting out of it? Like tokens per second?

22:55Speaker 1:That's great. It's as good as... Any frontier model that I've been using, I've been using GitHub Copilot CLI, mostly with Claude Sonnet. It's as good as that. I don't find myself waiting around. And it can do anything that I throw at it. It handles local stuff on the computer, stuff in Azure, in GitHub. It's just really good. This model compared to other models is good, but you run it in Lama CPP. And it's like beautiful on this particular configuration. I've found the sweet spot. So I wrote a document and that is the link that we'll put on the page. It's a GitHub. Read me basically running Quinn 3.8, 27 B with Lama CPP and GitHub co-pilot CLI on windows. And it tells you exactly how to install everything, all the stuff that you got to go, put everything where it needs to go. And like, Download Quinn and run it and how you access it remotely.

24:03Speaker 1:It's great. So I have my dev machine. I have my GPU machine. And it's a match made in heaven.

24:13Speaker 2:There's not a lot of people running those kinds of headless systems with Windows.

24:18Speaker 1:They're mostly Linux.

24:18Speaker 3:Right.

24:19Speaker 1:Cool. It's good. And also, this model, Quinn 3.8, has vision support. So I can paste screenshots in, you know, and it just works. It's wonderful. Cool.

24:31Speaker 4:Yep.

24:31Speaker 1:That's what I got. Richard, who's talking to us?

24:33Speaker 2:Grabbed a comment off of show 1963, which you did last year with one Michael Howard.

24:37Speaker 3:Yay.

24:38Speaker 2:Talking about 30 years of application security. This is back when you were still the red teamer. I know your life is different now. And this comment comes from also a past guest, Arnold Axelrod, who said, great show as always. One comment regarding input validation, because of course we talked about input validations. Toward the end of the show, Michael mentions that all input should be considered evil and must be validated in order to be considered secure. Yeah, hard to argue with that. I'm not a security expert, but I have a different take on that. I don't think that the problem lies in the lack of input validation, but I think that input validation should be a business requirement.

25:10Speaker 2:The example being zip codes. I don't necessarily know what a formal zip code is or will ever be consistent around the world. Answer is absolutely no. When you consider the idea that Ireland only got postal codes in 2015, like good luck. In my opinion, the problem lies with the use of parsers and interpreters and not using escape sequences or other structures to separate arbitrary input from structure ones, like separating the inputs from the SQL statement itself appropriately.

25:35Speaker 2:Both SQL, JavaScript, and command through the process start in C-sharp are interpreters, and if you construct an input to them that contains an arbitrary user input without sanitizing it with the correct escape sequences is where unpredictability comes to play, which causes the risk. A URI also having structured format that is parsed by a browser and constructing a URI, let's say, with an arbitrary query string, that may be harmful, but you're probably using URI encoding on the inputs, and that should leave you safe. This doesn't require you to limit the input in any way, just to format it correctly.

26:09Speaker 2:There is where the focus should be, as far as I'm concerned, not just to invalidate all inputs. I'd love to hear your opinions on it.

26:15Speaker 3:You want my opinion?

26:16Speaker 1:Go for it. Yeah, hit you.

26:18Speaker 3:You know, it all got turned on its head, right? With LLMs and jailbreaking. What is the input? What is it? What is valid? Can you even escape it? Even escape versions can still get through any kind of checks. So, yeah, I just wrote about that recently. Yeah.

26:35Speaker 2:Our new injection attack starts with ignore all previous instructions.

26:39Speaker 3:Exactly. So, Mike Resinovich actually has a t-shirt with that on the back. He showed it to me at Build last time and I almost fell over laughing.

26:50Speaker 1:It's the best.

26:51Speaker 3:He was so proud of it. He said, hey, Michael, check this out. It's completely turned on its head. And that's why we've got all these other defenses that come into play and these guardrails and so on in LLMs. It's because we need them. We don't know what the input is.

27:07Speaker 1:Yeah. LLMs need to get a sense of humor, right? A sense of sarcasm, a sense of irony. And they got to get sensitive to that just like we humans do. I think.

27:17Speaker 3:I don't know.

27:18Speaker 2:Yeah, we really want to pass every input through an LLM to say, is this a potential attack?

27:22Speaker 1:Yeah, good luck with that. No, but of course not. But I mean, if you're dealing with an LLM and you're at the keyboard and talking to it, right? And you give it some ridiculous prompt, you know, that's clearly satirical or something. It should laugh back at you, you know?

27:38Speaker 3:Well, that happened to me once.

27:40Speaker 1:Yeah, that's a good one. Yeah.

27:41Speaker 3:Dude, that happened to me once. All seriousness.

27:43Speaker 2:Really?

27:44Speaker 1:Yeah.

27:44Speaker 3:I was working on the podcast website or something and asked it to do a quick security review of the code. And it found something. I was just running Visual Studio, I think. And it found something and it said, here is a, I don't know, it was an outdated HTTP header. It had been deprecated. I didn't know. A supposedly security header had been deprecated. And it said, by the way, this HTTP underscore blah, blah, blah has been deprecated for security reasons. And it's really ironic that you as the author of Running Secure Code didn't find this.

28:18Speaker 1:Oh, that's great.

28:20Speaker 3:Yeah.

28:21Speaker 1:That's what I'm talking about.

28:22Speaker 3:I don't know what the backend model was because, of course, Visual Studio, you can jump around, but I don't know. But yeah, it was quite happy to yell at me and laugh at me.

28:30Speaker 1:That's pretty good.

28:30Speaker 2:When the tool says the word, it is trying to detect irony. That's just ironic, actually.

28:36Speaker 3:Right.

28:36Speaker 1:Yeah.

28:37Speaker 2:It's very recursive. Arnon, thank you so much for your comment. And a copy of Music to Code By is on its way to you. And if you'd like a copy of Music to Code By, write a comment on the website at. netrocks. com or on the Facebooks we publish every show there. And if you comment there and I read it on the show, we'll send you a copy of Music to Code By.

28:50Speaker 1:Or if you'd just rather buy Music to Code By, go to musictocodeby.net. You can get the tracks in MP3, WAV, and FLAC formats. Well, before we introduce Michael... Let's take a little break for these very important messages. And we're back.. NET Rocks. I'm Carl Franklin. That's Richard Campbell. Hey. And that's Michael Howard. Let me introduce him formally. Your bio has changed a little bit. Michael Howard's been at Microsoft since 1992.

29:19Speaker 2:Wow.

29:19Speaker 1:Always in some form of security, IIS, SDL, the founder of SDL?

29:25Speaker 3:Well, he's one of the guys that worked on the very, very earliest versions. It was like two or three of us, yeah, back in the day.

29:30Speaker 1:Awesome.

29:31Speaker 2:And that was the security lifecycle?

29:33Speaker 3:Security development lifecycle, yeah. Back in the earliest, like, 2004.

29:36Speaker 1:Also uh you worked in azure data on the red team last time we talked and now you're in post quantum crypto.

29:45Speaker 3:Woohoo yeah baby Man, I'm happy to be here, too. It's a lot of fun.

29:52Speaker 1:I mean, how can you have post-quantum if we haven't had quantum?

29:57Speaker 3:Because the real attacks start post-quantum. That's the reason why.

30:01Speaker 1:Yeah, you're right. I get it. You need to be ready.

30:05Speaker 3:For certain things. Certain things, maybe not. But we can discuss that later.

30:08Speaker 1:But yeah. Well, what does it mean, post-quantum crypto?

30:11Speaker 3:Well, you think of things in three ways. This is the way we think about it at Microsoft. Anyway, I'm sure most of the industry does. um, data, data in transit, data at rest, and then cryptographic trust. So data on the wire, you know, stuff flying across the internet is probably protected by TLS today, more than likely perhaps SSH, but certainly TLS data at rest is encrypted most of the time or should be. And those encryption keys are wrapped with other keys, uh, key wrapping keys. And then you've got cryptographic trust, which is, you know, signatures, certificates, all that sort of good stuff. Um, The real threat is dead on the wire is being, you know, being pulloined as it flies across the wire.

30:54Speaker 1:Yeah.

30:55Speaker 3:And then when a quantum computer comes out in the future, that stuff can be broken. And the breaking aspect is essentially just breaking the RSA or the elliptic curve wrapping... that goes on and out pops the AES key that's used for the bulk encryption, and now you just decrypt everything. And in the case of data at rest, it's the key wrapping keys, right? They can be broken because they usually, for example, RSA, which can be broken with an algorithm called Shor's algorithm, S-H-O-R.

31:23Speaker 1:Yeah.

31:24Speaker 3:And it basically finds periodicity in the way those algorithms work. That's what it takes advantage of.

31:29Speaker 1:Are our logs at risk for being pilfered by cryptos?

31:35Speaker 3:Post-mortem crypto? I mean, if it contains sensitive data, which you shouldn't be logging sensitive data, right? No, no, no.

31:40Speaker 1:But even if it wasn't containing sensitive data, is that something because it can go through so much data so fast that it could.

31:48Speaker 3:I mean, if I had to prioritize stuff, I would focus on the actual data itself.

31:51Speaker 1:Yeah, okay. So data in transit and then real data in your databases.

31:55Speaker 3:Correct. Yeah. And then those, again, they can be snaffled. today and then once a quantum computer is made available and.

32:02Speaker 1:That's where a lot of did you say snaffled.

32:04Speaker 3:Are stolen snaffled purloined.

32:06Speaker 1:Snaffled that's a good british.

32:08Speaker 3:Word snaffled yeah um there's actually a real word i don't even know is it a real.

32:13Speaker 1:Word it doesn't matter i i don't know but i never heard it.

32:15Speaker 3:Before it is now there you go things you.

32:18Speaker 1:Learn on dot numrocks all right It's all good.

32:22Speaker 3:Yeah, so the risk is the asymmetric keys that are used to wrap the symmetric keys that do the- Because they're dependent on prime numbers. In the case of RSA.

32:30Speaker 1:Yeah.

32:30Speaker 3:But that's not the attack. The attack is the periodicity. There's a periodicity. If you actually look at the way Shor's works, not that I say, not that you should, it basically does a quantum fast Fourier analysis.

32:41Speaker 1:Yeah.

32:42Speaker 3:Shor's is actually hybrid. It's actually quantum and sort of, classic computing. The hard work is done by Shor's and then some of the less difficult work is done classically because it's just easier. And so the real issue is that those asymmetric keys, RSA, elliptic curve, Diffie-Hellman, they all exhibit some periodicity that can be detected by Shor's. And that gives you a whole bunch of possibilities that then classical computing can then just sort of sift through and find out which ones are the actual keys. Right.

33:14Speaker 2:So it narrows the scope of the testing needed.

33:16Speaker 3:Correct. Yeah. And to your point before, rather than, you know, squillions of ages of the universe, it could be hours or days. Yeah.

33:24Speaker 1:Right.

33:25Speaker 3:You know, it's, it's, it's a real thing. And, um, you know, developers have a big part to play in, in this. It's not just, you know, flip some switch and everything's golden. Um, There's a lot more to it that developers need to understand as well.

33:42Speaker 1:So everything I've barely hung on understanding about quantum is that we're all screwed, right? And because of the way that TLS works and SSL and all that stuff, it dramatically has to change, doesn't it? If we're going to be less susceptible to quantum interference but you're i think what you're saying is that there are ways that we can do that now and that's what you know post-quantum crypto is all about is trying to use cryptographic methods now that will survive the quantum onslaught is that what you're basically up against yeah one.

34:27Speaker 3:Of the beauties of tls by the way i can't believe you said ssl like wash your mouth out.

34:33Speaker 2:You know, some of us were around in the 90s.

34:38Speaker 1:So was I. And so they don't use those words, TLS.

34:42Speaker 3:I know. Anyway, I'll just pretend you didn't say that. Yeah, so TLS, one of the beauties of TLS is that it's very agile, right? You can change the way it works, the ciphers that are used, the cryptographic primitives that are used.

34:57Speaker 2:And you're talking about TLS 1.0.

35:00Speaker 3:Correct. So TLS 1.2 should be using.

35:02Speaker 1:Yeah.

35:03Speaker 3:So actually that's a really important point. So TLS 1.2 and prior, so TLS 1.0 and 1.1 are deprecated anyway, so don't use them. TLS 1.2 does its cipher suite and its key establishments and authentication all as one string called the cipher suite. It looks like someone sneezed on the screen basically. It's a list of all the algorithms that are used for all of those things. TLS 1.3 is different. it broke apart things like the key establishment from the bulk encryption and the bulk tamper detection. They're completely broken apart.

35:33Speaker 1:Yeah.

35:33Speaker 3:So you can negotiate the two separately. That's the big difference in TLS 1.3. So the key establishment is a thing called a group. And the reason why it's called a group is because mathematicians got to hang on this. And they said, you know, all these things are mathematical groups. So we'll call them groups. Terrible name. But for the key establishment, that's where you set the algorithm or algorithms in some cases. And then after that, separately, is how you do bulk protection of the data on the wire.

36:05Speaker 3:So TLS 1.3 broke those two apart. So it is completely not compatible with TLS 1.2. And TLS 1.2 will never be post-quantum. I mean, it's just software. I mean, essentially, I suppose it could make it post-quantum.

36:17Speaker 2:Yeah, but why would you?

36:18Speaker 3:But the interoperability... well, the interoperability story would be horrendous. Like no one would do it.

36:23Speaker 2:But it also seems unnecessary too, right? Because I set the TLS 1.3 with a dropdown in Azure.

36:28Speaker 3:Right. But the thing is, here's the issue. And this is one thing that we're having to work on for products like Front Door, for example, is you will be able to control the group, not just the bulk cryptography that's used.

36:42Speaker 1:Okay.

36:42Speaker 3:And that's where, and the group is where the post-quantum part comes in. For the most part, symmetric stuff AES-256, SHA-384, and so on, which are the baselines, are fine. There's another algorithm there called Grover's, which is an attack against symmetric algorithms. And it essentially cuts the number of bits in the key in half. So if you have an AES-256 in a quantum world, that's the same as AES-128. Interesting.

37:06Speaker 1:Which is fine.

37:07Speaker 3:So you must use AES-256 and SHA-384 as the minimum as well. They're kind of okay.

37:14Speaker 1:They're fine.

37:14Speaker 3:The problem is the asymmetric stuff. Right. Yeah. Elliptic curve, RSA, Diffie-Hellman. That's where the problem is. Now, the nice thing in TLS 1.3 is that's defined in a group, and that's negotiated separately from the bulk cryptography. And that's where the hybrid algorithms come into play. And the reason why they're called hybrid is you use two together. You use elliptic curve and MLChem. So MLChem is the quantum resilient algorithm. Elliptic curve is classic. you build up keys in both, you smush them together, pass it through a hash, and then you derive the session keys after that. So they're both used together.

37:54Speaker 1:So that would have to be implemented both at the browser level and at the server level, right?

37:59Speaker 3:Yeah, everywhere. I mean, you say browser, but client. I mean, I just mean clients in general.

38:04Speaker 1:Yeah, clients, sure.

38:04Speaker 3:And in fact, you bring up a very important point there, Carl, and that is that all modern browsers support hybrid TLS 1.3.

38:12Speaker 1:Yeah.

38:13Speaker 3:So the, I mean, even the humble Xbox has hybrid. I've tried all sorts of, you know, iOS, Android, Windows, Mac, Linux, and all the common browsers support.

38:25Speaker 1:So anything, anything that uses it like curl or any, any little command line tool, all, all those things have to support it.

38:33Speaker 3:Correct. Correct. So SSH, both client server supports it as a version 10, I think maybe 9.9 or 10. supports um ml chem so the the important part there in the in ml chem is the letter l in that there's lattice and the two major algorithms that are post quantum resilient there's actually a small number but the two major ones ml chem and ml dsa the l is lattice and the is that lattice construct that is quantum resilient.

39:01Speaker 1:Right so when you say quantum resilient do you mean what you perceive as the first generation of quantum or all quantum going forward till the end of time?

39:10Speaker 3:Nah, I mean, NIST is still going through other algorithms. The industry has settled, and NIST has settled on MLDSA and MLChem. And there's been a lot of research for the last 20-something years in lattices, looking at it through a quantum lens, and they look good. but everyone's you know quite happy to say let's you know let's go look at other algorithms as well just in case and in fact for no other reason than the resulting cipher blob is big so i'll give you an example If you have an elliptic curve, say an EC25519, which is a curve, the signature, a digital signature for that is 64 bytes in size. It's pretty small. If you take an MLDSA87 certificate and you sign data with the private key of that, it's about 4.5K. So you imagine if you've got a whole series of certificates all with their signatures...

40:04Speaker 3:it adds up real quick.

40:06Speaker 1:Yeah.

40:07Speaker 3:And you can have problems with MTUs, with people passing stuff on query strings, amounts of space set aside on disk for signatures, you know? Yeah, so it's a real issue. So NIST is continuing to evaluate other algorithms with an eye to potentially smaller signatures. So now I get.

40:30Speaker 1:Why it's called Lattice because it kind of makes a web of data that's hard to penetrate. Is that good analysis?

40:37Speaker 3:No, it's terrible.

40:38Speaker 1:Terrible. It's terrible.

40:42Speaker 3:I can take it. Okay, here's how lattices... I claim stupidity. It's all good, mate. So, the way lattices work, and this is a terrible description, but it's an interesting way of thinking about it.

40:55Speaker 1:It'll be better than mine, I guarantee it.

40:57Speaker 3:I may not be. I'm not a fan of analogies, so here's an analogy for you.

41:00Speaker 1:Okay.

41:03Speaker 3:Imagine a chessboard, right? Eight by eight with a knight. We know the knight moves either one and two or two and one, right?

41:09Speaker 1:That's all it does.

41:10Speaker 3:Yeah. If I give you an end point and I give you a starting point, what route does the knight take to get there? That's pretty straightforward to do, you know, because it's just eight by eight. Now, imagine if that was a squillion by a squillion chessboard. Right. All right.

41:26Speaker 1:Got it.

41:26Speaker 3:Oh, no. You know, it gets harder. Now, imagine it's a thousand dimensions, right? Now imagine I don't tell you there's one by two, it's N by M.

41:35Speaker 1:Right, okay.

41:36Speaker 3:Now, just to make things even more difficult, it's not like an air quotes square chessboard. The squares are kind of funky shaped. They're not quite squares. And that's a thing called learning with errors. So that's hard. Here's a point somewhere in this N dimensional space. Here's your starting point. How do you get there? And so essentially the N by M is essentially like the private key. That's one way of looking at it. Terrible analogy, but it's about as close as you can get without introducing math.

42:04Speaker 1:Okay.

42:05Speaker 3:Yeah.

42:05Speaker 1:All right. Good. And so you don't think that quantum computers could ever get so good that they could just figure that stuff out quickly?

42:14Speaker 3:You mean when you throw in some AI as well? Yeah. Yeah. Go on.

42:19Speaker 2:But nobody ever comes up and thinks, hey, we've solved cryptography. You're always looking at new algorithms. You're always looking at new key lengths. We expect to routinely replace our algorithms.

42:30Speaker 1:It's an arms race.

42:31Speaker 2:Because the bad guys are fighting back.

42:34Speaker 3:Which is a beautiful segue into the next topic, which is crypto agility. If nothing else, from a developer perspective, one thing that post-quantum crypto will bring to the table is the need for crypto agility. what happens if you wrap some keys in MLChem? Chem stands for key encapsulation method. Let's say you wrap some keys in that and it ends up being broken five years, 10 years from now. How can you update your application to use a new wrapping method without breaking your existing, like you can still read your old data, but you would write out using some MLChem + + or something. Right. And crypto agility is just, so important. It's really brought it to the forefront as a need, because we don't know long-term if these things will be successful or not. And again, to your point, Carl, cryptographers are very, very conservative when it comes to these sorts of things, and they want to have a big security buffer, knowing that some things will start to potentially creak a little bit.

43:39Speaker 2:And of course, you're immediately going to the at-rest encryption problem. I'm always thinking TLS, and it's just we handshake an encrypted stream, we do our thing and then it disappears again. And so I don't have the, other than the, you know, harvest and decrypt later, I don't have to think about this. It's all transitory. We'll just use the newest algorithm. But if you've stored under an older algorithm, And now it's been breached. You have to decrypt, recrypt, or at least, you know, decrypt over time to get by that.

44:11Speaker 1:You may have to increase the data size of your fields that take those things because it's going to take more. Yeah.

44:16Speaker 3:So you've got to assume that there will be change. And unfortunately, a lot of people don't know how to build crypto agile solutions. It kind of drives me a bit bonkers, to be honest with you. I see, you know, in the press, you know, we need crypto agility. I've got to do crypto agility. Yeah. hey, crypto agility is really important. Are you guys doing crypto agility?

44:32Speaker 2:Because it comes in a squirt bottle and you just spray it on all your devs and you'll be good.

44:37Speaker 3:I know, but no one says how to do it. To me at Microsoft, there's two canonical examples of crypto agility. One is as a SQL DB or SQL server with always encrypted. And then the other one is the open office XML file format, which you use to encrypt documents in office. So the way it works in as a SQL DB, which to me is a beautiful and simple way of doing it. It's also very, very fast. If you ever look at the ciphertext in an always encrypted cell, the first byte is always a one, and that's the version number. And that basically means AES-256 cipherblockchaining with a SHA-256 hash as an integrity check over the data. So in the future, if they decide to upgrade it to something else, then that could be version two. So the first bike would be a two and they could always read back and say, okay, that's version one. We need this particular set of cipher primitives. Let's read as decrypted with these primitives. When they write it back, they would write it back as a, whatever the latest number was, which we version two, and it will be the, whatever the new, the new cipher suites is. So you can

45:43Speaker 3:always read the old data and you would write back using the new version. And the way office does it is it's an XML file. There's an XML file header. And it contains all the cryptographic primitives, like AES, it's cipher blockchaining, here's the initialization vector, here's the password, the key derivation count, here's the key derivation algorithm, and lots of other metadata. So you can actually build the cipher collection completely dynamically, which is really, really nice.

46:16Speaker 1:What network hardware will have to change in the, yes. I mean, we won't, we'll be able to go to Best Buy or whatever it is you have in the UK and buy an off the shelf, you know, router that is crypto happy. Oh, I mean, in theory, I think a lot of quantum happy rather.

46:34Speaker 3:I mean, unless they're doing some kind of inspection, if they're just like passing data on, there should be no need for it, right? They're not decrypting stuff, but if they are decrypting stuff, then yeah, they're going to have to have access to these algorithms. If you're doing, you know, TLS termination, then yeah, for sure.

46:48Speaker 2:The other that's not something you'll have in your home i did that stuff in racks of computers for companies but ah but.

46:54Speaker 3:There's a fly in the ointment there's a huge fly in the ointment though and that is your laptop and your computer with tpms and trusted boots and that sort of stuff right right now those keys are probably rsa and well they are rsa or elliptic curve.

47:06Speaker 2:They are and we're just going through the secure boot crisis thanks very much right.

47:09Speaker 3:So that will all get that will all get busted and um you know so the hardware industry out there We're being mean here, Michael.

47:17Speaker 1:Richard's squinting, but I think you've got to look at it like this. Hey, you've got to buy a new laptop. That's not a bad thing.

47:24Speaker 2:But it's also like we're fixing keys all the time. These are BIOS updates. This will come in firmware.

47:31Speaker 1:You think? There'll be new drivers.

47:34Speaker 2:And they might be slower than a hardware-dedicated version of it, but I just don't feel– a lot of the stuff you're describing here, Michael, to me sounds like configuration settings in Azure. you've already done the work in the browser. Like, as long as I haven't done anything stupid in code, I don't think I have to do anything as a web dev.

47:51Speaker 3:That's correct. 100% correct.

47:53Speaker 2:I just got to make sure that my admins have set stuff right.

47:55Speaker 1:Well, if you're using IIS, you're going to have to make sure you're in the latest version that supports it. But in Azure.

48:01Speaker 3:Well, http.sys... So I actually wrote a blog post on this because about six-ish weeks ago, we released a version of S Channel, which is the Windows TLS stack that supports TLS 1.3 hybrid. And I wrote a dumb ASP.NET application, you know, dumber than a bucket of rocks just to keep it really, really simple and did no configuration whatsoever in the code. And that's a really important point. Like, you know, thou shalt not do any TLS configuration in code, like leave it to the OS or to some configuration somewhere else, definitely not in code. And yeah, I just turned on that. I wanted X35519 MLChem768 in priority zero.

48:43Speaker 3:in the Cypher suite and group order. And I ran this application and I connected it, connected using a browser and I was living in the future.

48:52Speaker 4:Nice.

48:53Speaker 1:Michael, how long do we have before we need to configure things correctly?

48:58Speaker 3:How long do we have? I mean, I mean, it depends on risk. I was talking to a large retailer. You know who they are, but I can't say who they are.

49:08Speaker 1:Perfect.

49:08Speaker 3:And they're not concerned.

49:09Speaker 1:The one I bought my computer from?

49:10Speaker 3:They're not concerned about right now anyway with their devices that they use for shop floor inventory management, right? Because it's just shop floor inventory management. It's not sensitive data. So their Android devices that they're using will never support post-quantum. They're okay with that. Now, their corporate systems that run HR and payroll and all that sort of stuff, yes, they do care. So how long do we have? I mean, the clock started now for certain types of data. Depends on the data. If you've got really sensitive data or data that must be secret for a long time, healthcare information, military secrets, intelligence, financial records in some cases, perhaps. I don't know. I'm not a regulatory person. You know, they have a time that they must maintain their secrecy. And that clock's already started. Because if we take a 2029, 2030 timeframe, that's only four years. It's not even four years away. Hmm.

50:08Speaker 1:On the screen behind you, a sentence came up a little while ago. There's no such thing as low-risk data. But apparently this large retailer seems to think there is.

50:17Speaker 3:I think it said no low-risk secrets.

50:21Speaker 1:Oh, low-risk secrets. That's right. Yeah.

50:23Speaker 3:Yeah. Low-risk secrets.

50:25Speaker 2:Secret is secret.

50:25Speaker 1:So, if it's a secret by default, it's by definition a risk.

50:29Speaker 3:Well, a small, air quotes, small secret can lead to access to bigger secrets. Like a low credential, for example, it can lead to something like a key.

50:38Speaker 1:Sure.

50:38Speaker 3:Yeah.

50:38Speaker 2:The old classic, I got your Wi-Fi password from your light bulb because you thought, well, it's just a light bulb.

50:45Speaker 1:What are you going to do to me? Right.

50:46Speaker 2:But the fact that I got chain attack, once I got into the wifi, there was a whole lot of other things that were there.

50:51Speaker 3:Yeah. And that's why I put all my IOT stuff on his own virtual network is our own isolated.

50:56Speaker 2:Oh, you're darn right. You do.

50:57Speaker 1:Absolutely. Yeah.

50:58Speaker 3:Yeah.

50:59Speaker 2:But, uh, at the same time, you know, it's still, I'm still sorting through what do I have to code as a dev versus what I have to, uh, you know, what's going to come to me, uh, just by making sure we're using the latest bits. I love your info on always encrypted. It's like, hey, now I want to go talk to my DBA. And it's like, we're up on this version, right? Because we have all this encrypted and REST stuff, and you don't want a crisis. So if you're already running always encrypted in SQL, then we should be good. When the new algorithms are needed, they'll work.

51:34Speaker 3:The big issue, and this is one thing that a lot of products at Microsoft are having to deal with, is the symmetric stuff's fine. It's the key wrapping that has to change. The beauty of it, though, is it's just the key wrapping. So if you have a 256-bit AES key, you just decrypt it or unwrap it using RSA, for example, and then you rewrap it using AES-KW. which managed HSM in Azure, and now Key Vault, actually, Key Vault Premium in public preview, supports AESKW key wrapping, which is post-quantum resilient.

52:05Speaker 1:Yeah, go ahead.

52:06Speaker 3:So there's two issues that I see developers need to really, really think about. The number one is please don't put any TLS anything in your code.

52:15Speaker 2:Yeah, it'll hurt you later.

52:16Speaker 3:Don't restrict protocol version. Don't restrict cipher suites. Don't do any of that. Just let it be configured completely outside of the application. That's number one. Number two is this whole crypto agility thing. If you've got crypto code with the algorithms hard-coded in the code.

52:37Speaker 2:You're in trouble.

52:38Speaker 3:And you're encrypting squeaky bytes of data... You know, you've got to update your code and probably can't read the old data. So now you've got, you know, it's just a mess. And that's where the whole crypto agility comes in. And honestly, if you haven't got crypto agility in place, there are patterns you can use to wrap existing non-crypto, crypto agile blobs into like some sort of crypto agile envelope that contains all the metadata.

53:03Speaker 1:So Azure's really good about letting me know when I need to move off of some version of something and onto something else because it's being deprecated. Do you think that sometime in the future, we're going to get an Azure thing when we log into the portal that says, hey, you need to upgrade your whatever it is to be quantum happy. You think that's going to happen? Like, should I just leave it up to Azure to warn me about things like that? Or is there stuff that I need to do now?

53:34Speaker 3:I think it depends. If you look at the shared responsibility model, that's where it really becomes important. Like if you've got a platform managed key to encrypt data, then we're going to take care of that, right? Because a platform managed key. But if you've got a customer managed key, which is basically a key wrapping key, then they'll probably look at, I can't predict the future, but my guess, just my guess, Is that there will be notifications to say, hey, you know, we've now got the ability in Azure, blah, blah, blah, to wrap your encryption keys in quantum resilient keys. Would you like to do this? Yeah. And click here. Yeah.

54:11Speaker 2:And the consequence is going to be very likely that the data streams are going to get larger because the quantum resilient keys are bigger. But I don't know what other impacts I'm going to see.

54:22Speaker 3:No, you shouldn't see it. No, because the only thing you're really changing is the key wrapping. Right. Which is, so if you've got a 256-bit AES key, you're going to wrap it in AES-KW. And in fact, it'll probably be smaller than RSA, to be honest with you. But if you wrap it in MLChem, it will be bigger.

54:39Speaker 1:Right.

54:40Speaker 3:Yeah, but it's just the key.

54:41Speaker 1:It's just the key.

54:42Speaker 3:Yeah, the data doesn't change.

54:43Speaker 2:Am I even choosing that or I'm just configuring to allow this and it'll optimize itself?

54:49Speaker 3:No, what do you mean? When do I have to make a decision about this, about the rewrap? Well, first of all, the nice thing is it's very low friction. Right. Very, very low friction. Like it's microseconds to do the work. You're not decrypting and re-encrypting petabytes of data.

55:07Speaker 1:Right.

55:07Speaker 3:So my guess is personally, as soon as it becomes available, I would just opt in and just re-wrap your keys.

55:15Speaker 2:So I'm going to wait for your blog post and then I'm just going to switch this stuff on.

55:19Speaker 3:No, we'll push it through Azure Update.

55:21Speaker 1:Okay.

55:21Speaker 3:I guess it'll be through the Azure Updates website.

55:24Speaker 1:Yeah.

55:24Speaker 3:Yeah. Yeah.

55:24Speaker 1:Good. And is this imminent like in the next year?

55:27Speaker 2:Yeah.

55:28Speaker 1:Wow.

55:28Speaker 3:It'll depend on the service. Yeah. So, so, so I really want to point something out here is that, you know, this post-quantum stuff is very layered, right? So the very bottom of the layer, you've got the algorithms. Well, that stuff's been in place in windows for.

55:39Speaker 1:For ages.

55:40Speaker 3:Um, we have called sim crypt available in windows, Linux and Mac hand optimized C code. Absolutely beautiful to read. It's so well written. Honestly, it really is. Then above that, you've got, um, say TLS 1.3 with hybrid, right? You open those floodgates because now people can use that stack. So basically on windows is to use the new S channel stack. And in the case of Linux use open SSL 3.5, um, which has ML chem built into it. So you've got those two options are now available to you. Um, so that's, that's the data in transit taken care of.

56:11Speaker 3:And then the last one, which is incredibly important is the key wrapping. And we now have that in, in Azure. So managed HSM has had a key wrapping since day one. And, um, as your Key Vault now has it, ASKW. So what's going to happen is that's going to open these floodgates and there'll be a Cambrian explosion of services coming online right as they adopt. And look, it won't happen like overnight, because everyone's going to do testing, make sure it works, make sure it fails correctly and that sort of stuff.

56:43Speaker 3:But Richard, to your point, next year, We'll see a lot of services rolling this out.

56:48Speaker 1:Starting to switch over.

56:49Speaker 2:But I also remember when we started switching up keys, when attacks got smarter and so forth, there was a period where we changed a number of times different flavors of, yes, SSL, and then into TLS. We are restarting this in some respects with these new cryptography. I've got to think. The first move we make may not stick for more than a year or two before it's like, hey, now we found some problems and you probably want to switch to this. I just remember going through this with AAS and a few others. Like, we've done this before. In some ways, we've gotten really lazy because it's worked so well for so long.

57:27Speaker 3:Well, actually, it's worse than that. And that is that, so we've actually become really lazy because of RSA.

57:34Speaker 1:Right.

57:34Speaker 3:RSA is interesting. RSA can do all the crypto primitives. Right. It can do signing, it can do encryption and all that sort of stuff. Elliptic Curve and Diffie-Hellman cannot. They can't do everything. And so we've been used to, like you said before, Richard, I'm not trying to laugh at you, but he said, you know, prime numbers. Well, that's just an RSA thing. That's not an elliptic curve thing. Right. Because everyone thinks of RSA.

57:55Speaker 1:Yeah.

57:56Speaker 3:And RSA is this Swiss army knife. It does absolutely everything.

57:59Speaker 1:Sure.

57:59Speaker 3:And the problem is it does absolutely everything.

58:02Speaker 2:Absolutely everything.

58:03Speaker 3:Which means we've got to change it absolutely everywhere. Yeah.

58:06Speaker 2:It went everywhere. Well, the other side of this was because compute, I remember when it was expensive to do encryption, where we literally had separate servers from the website for doing just the encrypted pages. It's okay, well, now you're going to take your shopping cart and start a payment cycle that needs to be asked to sell. Now, it was this big thing about moving the cart over to the other much more expensive dedicated stack for completing a transaction.

58:34Speaker 2:Because encryption used to be so costly. You know, these days our CPUs are so damn fast. They're sitting around playing poker and smoking cigarettes waiting for something to do. So sure, encrypt everything. Who cares? RSA is fast.

58:47Speaker 3:Well, the funny thing is that first of all, it's just the key wrapping and unwrapping part.

58:51Speaker 1:Yeah.

58:52Speaker 3:Let's just call it key establishment because there's all different ways of doing it.

58:56Speaker 2:That's really what's going on.

58:57Speaker 3:That's the expensive part because it's all asymmetric stuff. And Windows, I think it still exists. There used to be a registry key called modexp offload for modular exponentiation offload, which is a very expensive RSA operation. And there was a way you could actually set a DLL in there, a name for DLL. It would actually offload that work to a DLL, which was a shim into some hardware to actually do the modular exponentiation work. But we don't need any of that stuff anymore. You know, when I look at the work that... you know, as your front door have done, for example, they've done a whole bunch of analysis on performance and the performance is like just a couple of percent, you know, going from elliptic curve to elliptic curve plus ML, ML chem. And that's because of optimizations made in the library.

59:49Speaker 1:Sure.

59:50Speaker 2:I got to tell you, Michael, there's this weird dichotomy going on where it's like the catastrophizing of quantum destroying everything and the, oh, just touch this button, problem goes away.

59:59Speaker 1:Yeah. Yeah. I'm feeling that too. You're right.

1:00:03Speaker 3:I wish it was that simple.

1:00:05Speaker 2:Yeah. I keep waiting for what's not the simple part. I mean, for me, it's the frontline dev.

1:00:10Speaker 1:Right.

1:00:11Speaker 2:I mean, the administrator in me is a little sticky in the shorts right now because this is all very scary. Like, I want to check everything. I don't want to be the guy who didn't do his homework.

1:00:21Speaker 1:Right.

1:00:21Speaker 2:But for the dev, unless you've done something dumb, I think you're good as long as your administrators are on it.

1:00:27Speaker 3:As I mentioned before, the two big dumb things are baking in crypto algorithms into your code and not being crypto-natural. That's dumb thing number one. Dumb thing number two is if you hard code your TLS configuration.

1:00:40Speaker 2:Right.

1:00:41Speaker 3:You're right. Those are the two big ones. Let's just ignore compatibility for a moment. If you change a server to use TLS 1.3 hybrid and only hybrid, by the way, the reason why it's called hybrid is because you do elliptic curve and MLChem together. The keys are derived from both. That's why it's called hybrid. But if you do hybrid and the client doesn't talk hybrid for whatever, you got like a crusty old Java application or C sharp application written 15 years ago, it's probably not going to work.

1:01:10Speaker 1:Yeah.

1:01:11Speaker 2:And it's really a question of, is it going to fail with some grace to tell you what the hell's going on?

1:01:15Speaker 3:Yeah.

1:01:15Speaker 1:Right. Yeah.

1:01:17Speaker 3:It says, don't understand this cipher suite and gives you a hex value. Yeah. Really useful.

1:01:22Speaker 1:Yeah.

1:01:22Speaker 2:Well, that's better than object not found.

1:01:27Speaker 3:One of the best ones in office back in the day was out of memory.

1:01:30Speaker 1:Yeah. Michael, tell us about your book.

1:01:33Speaker 3:Oh, my new book, man.

1:01:34Speaker 1:Yeah.

1:01:34Speaker 3:So, I wrote this book with Sean Hernan, Lee Holmes, and Sherry DeGrippo. So, Sean and I have known each other for many, many years. He's a partner engineering manager in Azure Security. I've been around for a long time, got the utmost respect for Sean, great guy. Lee Holmes, he was the security guy in PowerShell.

1:01:52Speaker 1:Yeah, he's been on the show before too.

1:01:53Speaker 3:Yeah, my boy Lee, great guy.

1:01:55Speaker 1:Yeah, he's a good man.

1:01:56Speaker 3:He and I actually worked together in the earliest days of the SDL because when Monad, as it was back in the day, had to go through all its SDL checks, I was the.

1:02:07Speaker 2:Precursor to PowerShell?

1:02:09Speaker 3:To PowerShell, correct.

1:02:10Speaker 1:Yeah.

1:02:11Speaker 3:I was like the SDL contact for Monad. And so Lee and I got to know each other incredibly well. And he's also a partner engineer in Azure. And then Sherrod DeGrippo, she's actually left Microsoft now. She goes to Palo Alto Labs. She is easily one of the preeminent experts in the world on threat actors. She knows absolutely everything about threat actors. So the book is Threat-Driven Software Development. And basically what it is is looking at software development through the eyes of threat actors, like what do threat actors actually do?

1:02:41Speaker 2:Mm-hmm.

1:02:42Speaker 3:And every chapter starts off... So first of all, Sherrod has her own chapter at the beginning. But every chapter after that looks at the contents of that chapter through the lens of threat intel. So every chapter starts off with anywhere between half and two pages of threat intel perspective, where Sherrod gives it a whole bunch of color. And then Lee, myself, and Sean go through and sort of explain that particular topic in detail. And a lot of it's...

1:03:11Speaker 3:A lot of it's not just, don't think of it like just security best practices.

1:03:15Speaker 1:It's not.

1:03:16Speaker 3:It's DevOps as well as it's operational security, AppSec, and also Threat Intel all sort of munched together into one book.

1:03:26Speaker 1:Sounds good.

1:03:27Speaker 3:Yeah, a lot of fun. I did one when I was in the red team. Funny thing is, so Mark Rasinovich wrote the forward. And my manager at the time, Craig Nelson, who's CVP of the red team, he said, oh man, I really love this book. I gave him draft to look at. Can I write a chapter? I'm like, well, why don't you write the afterword? I said, I've never had an afterword in a book. Why don't you write the afterword? So he did. Nine pages. But the afterword...

1:03:53Speaker 3:The after chapter. Yeah, the after chapter. Look, I'm not trying to besmirch Craig at all. That afterword is absolutely brilliant. If you were to sum up the afterword in like one sentence or two words, it would be So what? And he does a really, really good job of answering. So what? Yeah. It's really good. Yeah.

1:04:14Speaker 1:That's good. It's really cool. Michael, what can we say? It's been enlightening having you here and talking about all this crazy stuff that we barely understand. Well, I barely understand anyway, but I understand a little more thanks to you. So thank you very much.

1:04:27Speaker 3:You're welcome. Thanks for having me on.

1:04:28Speaker 1:Great show, friend. Thank you so much. And we'll talk to you next time on. NET Rocks!. NET Rocks!

1:04:54Speaker 4:NET Rocks is brought to you by Franklin's Net and produced by Plop Studios, a full-service audio, video, and post-production facility located physically in New London, Connecticut, and, of course, in the cloud, online at pwop.com. Visit our website at dotnetrocks.com for RSS feeds, downloads, mobile apps, comments, and access to the full archives going back to show number one, recorded in September 2002.

1:05:23Speaker 1:And make sure you check out our sponsors. They keep us in business. Now go write some code. See you next time.