Speaker 1: How'd you like to listen to. NET Rocks with no ads? Easy.
Speaker 1: Become a patron. For just $ 5 a month, you get
Speaker 1: access to a private RSS feed where all the shows
Speaker 1: have no ads. $ 20 a month will get you that
Speaker 1: and a special. NET Rocks patron mug. Sign up now
Speaker 1: at patreon.dotnetrocks.com. NET Rocks Hey, and welcome back to. NET Rocks.
Speaker 1: I'm Carl Franklin. And I'm Richard Campbell. And Michael Howard's
Speaker 1: here with us. We'll have him jump in if he
Speaker 1: wants to in the beginning. And we'll introduce him a
Speaker 1: little bit later after the first bits. You know what
Speaker 1: those are. Here we go. Here we go. 2020.
Speaker 2: It's episode 20 when we're almost done, right? Like this
Speaker 2: ends in 20 after 2026. So we got like six
Speaker 2: more of these.
Speaker 1: And it's becoming less and less interesting because most people
Speaker 1: have lived through the last six years.
Speaker 2: It's so current. Yeah. It's kind of now. Especially 2020,
Speaker 2: because of course, what can you talk about except COVID?
Speaker 1: Oh my God, COVID. All right, I'm done, Richard. What
Speaker 1: about space? Yeah, thanks for playing, guys.
Speaker 2: Well, the other thing I would talk about is this
Speaker 2: is when the UK officially leaves.
Speaker 1: The EU. Oh, there's more news, but COVID is the
Speaker 1: big one. George Floyd. It is the big one, yeah.
Speaker 1: George Floyd killed. Big, big reaction to that that sparked
Speaker 1: off a lot of stuff. Joe Biden beat Donald Trump. Yes, there,
Speaker 1: I said it because that's the truth. Worldwide economic collapse
Speaker 1: caused by COVID. Lockdowns. Yeah, it's just stall. It was
Speaker 1: just horrible. Donald Trump was impeached for the first time. Oh,
Speaker 1: in the first year. I was at the end. A
Speaker 1: lot of wildfires in Australia and Western US. The terrible ones.
Speaker 2: Know about and now and today it's really relevant in
Speaker 2: september the second nagorno-karabakh war so this is between azerbaijan
Speaker 2: and armenia this is an enclave that normally is controlled
Speaker 2: by armenia but the azerbaijanis wanted it and they attack
Speaker 2: and so the azerbaijanis are the ones with the oil
Speaker 2: money and they're muslim the uh the armenians are predominantly
Speaker 2: christian uh the azerbaijanis attack and to be clear this
Speaker 2: is a very complicated conflict like it's gone on literally
Speaker 2: for centuries But it was a drone war. It was
Speaker 2: arguably the first drone war.
Speaker 1: Wow.
Speaker 2: The Azerbaijanis bought Turkish Bayraktar drones. They had bought some
Speaker 2: of the surveillance equipment from the Israelis. And so they
Speaker 2: had continuous surveillance. They were using drones for attack. They
Speaker 2: destroyed missile sites and so forth. The Iranians were fighting
Speaker 2: the old style with Soviet equipment. and just kind of
Speaker 2: got rolled over. Like you'd think the Russians would have
Speaker 2: taken a hint watching their stuff be torn up by
Speaker 2: drones in 2020. Instead, they bought a lot of drones. Well,
Speaker 2: they did eventually, but first they got hit pretty hard. Anyway,
Speaker 2: it was only six weeks. And that doesn't change the
Speaker 2: fact that a lot of people died. It did result
Speaker 2: in the fall of the, of the region and the
Speaker 2: change in the, in the environment over there. But it's
Speaker 2: just a precursor conflict to, to, you know, we saw
Speaker 2: an example, just of course it was COVID and, There
Speaker 2: was all the things going on at that time in
Speaker 2: that year that nobody was paying attention to.
Speaker 3: Yeah.
Speaker 1: A couple other notable deaths in 2020. Ruth Bader Ginsburg.
Speaker 1: What a blunder.
Speaker 3: Yeah.
Speaker 1: Kobe Bryant. Yeah, the helicopter accident. And good trouble himself,
Speaker 1: John Lewis.
Speaker 3: Right.
Speaker 1: Died civil rights icon. Yeah. Yeah, it was just a
Speaker 1: bad- Tough year. Bad years. Tough year.
Speaker 2: Yeah. Do you want to know what happened in space?
Speaker 2: There wasn't a ton, but there's some important ones. In February,
Speaker 2: Solar Orbiter launches. You don't really know much about this one.
Speaker 2: This was a joint ESA-NASA mission in that order. It's
Speaker 2: very much a European mission with NASA instrumentations and They
Speaker 2: provided the Atlas V as well, but it was built
Speaker 2: by Airbus. And its goal was to get a view
Speaker 2: of the poles of the sun. Normally, you're launching your
Speaker 2: spacecraft because the Earth's in the plane of the ecliptic.
Speaker 2: Your spacecraft are going to be as well. Trying to
Speaker 2: get to high inclination is very, very difficult. Not that
Speaker 2: they got all that high. They'll fly down into a
Speaker 2: looping orbit inside the orbit of Mercury and then use
Speaker 2: Venus to do the slingshots and repeatedly tip the spacecraft.
Speaker 2: So it is about 24 degrees off the planet ecliptic.
Speaker 2: It takes a ton of energy to do that. They
Speaker 2: borrowed lots of energy from Venus, but it's a one-ton spacecraft,
Speaker 2: so it.
Speaker 1: Can do that.
Speaker 2: But it'll get us our first visual views of the
Speaker 2: poles of the sun.
Speaker 1: Cool mission. Yeah, that is cool.
Speaker 2: In May. the first crew dragon demo mission. So this
Speaker 2: was Bob, uh, Benneken and Doug Hurley go up to
Speaker 2: the space station and demonstrate that, uh, the commercial spacecraft
Speaker 2: can actually go to the space station properly. And that'll
Speaker 2: be followed up in November with a regular crew flight
Speaker 2: of four astronauts to crew the space station.
Speaker 1: So there you go.
Speaker 2: After what this would be nine years since the Atlantis
Speaker 2: had landed. And the only support for the station was, uh,
Speaker 2: Via Soyuz, now the Americans had a vehicle again, the
Speaker 2: former crew driver.
Speaker 1: I got a question, which Michael might know the answer to,
Speaker 1: but you said ESA and NASA did this thing together
Speaker 1: in 2020, but Brexit was in 2020. Was Was Britain
Speaker 1: part of ESA in 2020? Did they participate?
Speaker 3: Yeah, I don't think so. I could be wrong, but
Speaker 3: I don't think so.
Speaker 2: It's mostly Germany, France.
Speaker 4: Yeah.
Speaker 1: Okay. It's Airbus, it's Defense of the Space. All right.
Speaker 2: July, the Perseverance rover. So, this was the test article
Speaker 2: for the original Curiosity rover with a bunch of upgraded things,
Speaker 2: better wheels, better suspension.
Speaker 3: Yeah.
Speaker 2: New instruments, the Ingenuity helicopter, all of that stuff gets
Speaker 2: launched in July. July is the perfect time to launch
Speaker 2: to Mars, July 2020. There's a synchronicity to the orbits, right?
Speaker 2: They're in a two, three period. And so every roughly
Speaker 2: two years, you get a chance to do a bunch
Speaker 2: of flights. And so July, there's actually three. There's the
Speaker 2: Perseverance rover, which is huge. There's also China's very first
Speaker 2: mission to Mars, Tianwen-1. And then the UAE. the United
Speaker 2: Aramids launches their Hope climate orbiter to Mars. So three
Speaker 2: launches in the same month. Wow.
Speaker 3: Did they all make it?
Speaker 2: In October.
Speaker 3: The U.S. made it.
Speaker 2: They all make it.
Speaker 1: Yeah, actually. Very cool.
Speaker 2: And I mean, I'll talk more about the Tianwen-1 when
Speaker 2: it lands next year. So in episode 2021. Because that
Speaker 2: was China's first attempt to go to Mars and it
Speaker 2: fully worked. Nobody's pulled that off before. Everybody loses a
Speaker 2: few trying to get to Mars.
Speaker 1: Just name it. Everybody does. But China didn't.
Speaker 2: But, you know, the advantage of being, I don't know,
Speaker 2: fourth or fifth mover or something like that. In October, OSIRIS-REx,
Speaker 2: one of the asteroid missions, touches on asteroid Bennu. and
Speaker 2: collects a sample there. In fact, it does a little
Speaker 2: too well because when it touches, Bennu is very much
Speaker 2: a rubble pile and all that gravel goes everywhere and
Speaker 2: they actually have trouble closing up the sample container because
Speaker 2: there's too much stuff. They have to come up with
Speaker 2: such technical maneuvers as shaking a little off to try
Speaker 2: and get the thing closed up so they can put
Speaker 2: it in the capsule to return. Another asteroid mission at
Speaker 2: the end of the year in December, Hayabusa 2, will
Speaker 2: actually successfully return It's sample payload from the asteroid Regu,
Speaker 2: and that is a JAXA mission. A little recap on
Speaker 2: what SpaceX did in 2020. There was actually 25 launches
Speaker 2: from SpaceX, which at the time was an amazing number.
Speaker 2: Just remembering that SpaceX will do 150 this year. So obviously,
Speaker 2: there's the two Crew Dragons, the test run in March,
Speaker 2: and then the full payload in November. They'll also fly
Speaker 2: 14 Starlink missions, 833 satellites for a network of almost
Speaker 2: 900 by the end of the year.
Speaker 4: Wow.
Speaker 3: Have you ever seen the Starlink satellites leaving the spaceship? Yeah.
Speaker 3: It's like pizza boxes going out.
Speaker 2: Yeah, yeah. Well, now they've gotten bigger because of the
Speaker 2: V2 minis. And so, they only fly like 24 or
Speaker 2: 28 of them depending on the inclination. But at this time,
Speaker 2: they're flying 60 a run.
Speaker 1: That's crazy. Wow.
Speaker 2: Just these huge numbers of satellites. And that's where they also,
Speaker 2: this is the year where they have the reflectivity problems.
Speaker 2: And so you can see them for an extended period
Speaker 2: of time until they learn how to orient them and
Speaker 2: paint them correctly so they're not so visible and don't
Speaker 2: bother people so much.
Speaker 1: I remember there was a bunch of astronomers that were
Speaker 1: complaining they were polluting the night sky with their telescopes.
Speaker 2: Yeah. Well, and that's still an issue, although let's face it,
Speaker 2: digital processing can fix that.
Speaker 1: Right.
Speaker 2: But making bright lights make it worse. So making sure
Speaker 2: it doesn't reflect sunlight helps.
Speaker 1: I've seen them though. I've seen the trail go across
Speaker 1: and it's pretty fascinating and a little bit I don't know.
Speaker 1: You know, SpaceX does some things that if you weren't
Speaker 1: paying attention, you'd think we're being invaded by aliens.
Speaker 2: Well, or, you know, or Dr. No is in full swing.
Speaker 2: Like the line between supervillain and tech billionaire is getting
Speaker 2: very narrow.
Speaker 1: Just people don't know. Like, you know, the first time
Speaker 1: that I saw the booster rocket spinning, you know, when
Speaker 1: it– I thought it was like a spaceship. And so
Speaker 1: did a million other people until I found out, oh,
Speaker 1: that's just SpaceX. That's what they do. And what are
Speaker 1: those lights going? Hey, is that Santa Claus? No, that's
Speaker 1: just SpaceX.
Speaker 3: Yeah. I use Stellarium and it'll show you all the SpaceX.
Speaker 1: Sure. Something's whizzing around out there. I know. Must be
Speaker 1: my Facebook friends. They're at average intelligence or ability to
Speaker 1: look things up.
Speaker 2: 10,000 plus of them by the end of this year,
Speaker 2: just so you know. There'll be a bunch of other
Speaker 2: missions as well, including a couple of GPS satellites. They'll
Speaker 2: also start doing their Starship flights, the hop tests, and
Speaker 2: the first, what they called belly flop test, where they
Speaker 2: fire it up to a few kilometers up and then
Speaker 2: let it fall on its belly so they could actually
Speaker 2: land it. That was SN8 by the end of 2020.
Speaker 2: It does not go well, but they'll solve that and
Speaker 2: prove that this whole idea is even possible. All right,
Speaker 2: should we move on to computing?
Speaker 3: Yeah.
Speaker 2: We'll start in January with the OpenAI paper called the
Speaker 2: Neural Scaling Laws. Lead author is Jared Kaplan. There's a
Speaker 2: whole bunch of others, including Daryl Modi, who this time
Speaker 2: is at OpenAI, will eventually be the CEO of Anthrop.
Speaker 2: And this was the paper that sort of kicked off
Speaker 2: this idea of, you know, different from all the other
Speaker 2: machine learning models we did where we worry about overfitting
Speaker 2: and training sets and so forth. that for large language models,
Speaker 2: we should just train on as much data as we
Speaker 2: can possibly get. There's lots of debate as to whether
Speaker 2: this is that good an idea. We've definitely come into
Speaker 2: other techniques from there. But this paper is kind of
Speaker 2: the stimulus for what will be the insanity coming in
Speaker 2: the next couple of years. January is also when Microsoft
Speaker 2: switches over to Chromium as the rendering engine in the
Speaker 2: new Edge browser. The pandemic's in full swing in March
Speaker 2: is when lockdowns really kick off and everybody goes home
Speaker 2: and everybody's got Zoom. Teams explodes for better or worse.
Speaker 2: But a little thing I paid attention to was Terry Breton,
Speaker 2: who is the EU Internal Market Commissioner. reached out to
Speaker 2: Netflix and YouTube and Amazon Prime and asked him to
Speaker 2: turn off all the 4K features. He was concerned about
Speaker 2: the amount of available bandwidth across Europe as everybody went
Speaker 2: home and used the internet differently. Was it actually a crisis?
Speaker 2: Nobody knows for sure, or at least he's not talking
Speaker 2: about it. They started turning up the bandwidth again in May,
Speaker 2: and Netflix's Posts about this are interesting because they talk
Speaker 2: about network changes and increasing capacity and things like that.
Speaker 2: So maybe there really was a crisis because of the
Speaker 2: change in the Internet consumption due to COVID. But, you know,
Speaker 2: a lot of details aren't revealed necessarily. But that to
Speaker 2: me was very interesting.
Speaker 1: Yeah.
Speaker 2: April is when Uncle Satchit says, two years worth of
Speaker 2: digital transformation in two months. Because everybody had to all work.
Speaker 2: This is when I started doing True Run As a week,
Speaker 2: just talking about topics around what was necessary for sysadmins
Speaker 2: with everybody working from home.
Speaker 1: My brother is a programmer at a local company. He's
Speaker 1: been there for years and years. And they basically do
Speaker 1: online vehicle registrations. And they were the first in the
Speaker 1: area to do it. And their customers are states, not
Speaker 1: individual sales places, dealerships. But anyway, they were renting an
Speaker 1: office building in an office park out here, umpteen billion
Speaker 1: square feet. And during COVID, people went to work at home.
Speaker 1: And I just remember Jay coming to rehearsal once and said, Well,
Speaker 1: I've resigned myself to the idea that I'm never going
Speaker 1: back to the office. And they basically moved out of
Speaker 1: the office. Yeah, lots did. They stopped renting it. And
Speaker 1: I think, in general, office space took a big dive
Speaker 1: in 2020.
Speaker 2: You think about all the property that Microsoft gave up
Speaker 2: in Bellevue.
Speaker 1: Yeah.
Speaker 2: They kept their buildings in Redmond, but all that rented space.
Speaker 1: In Bellevue went away.
Speaker 3: Right.
Speaker 1: And all of it went to Zoom.
Speaker 3: Yeah.
Speaker 1: Well, to Teams.
Speaker 2: Teams. The first virtual build in May is also when
Speaker 2: they do the full release of Blazor WebAssembly.
Speaker 1: Yeah.
Speaker 2: Obviously, a bunch of other cool announcements around building that
Speaker 2: time span. Of course, Blazor, not the first WA programming language,
Speaker 2: Golang added WA support back in 2018. In June, and again,
Speaker 2: no people remember much about this because it was mid-pandemic.
Speaker 2: Microsoft is a big splash about OpenAI GPT-3 being built
Speaker 2: on what they called the Azure supercomputer, which was a
Speaker 2: bunch of different Azure data centers harnessed together with 10,000 GPUs, 285,000 CPUs.
Speaker 2: cpu cores to build a get this 175 billion parameter
Speaker 2: model wow i mean big big big for the time
Speaker 2: not so much anymore but at the time.
Speaker 1: I remember uh brian mckay who's one of my happy
Speaker 1: next guys getting on slack and telling us how awesome
Speaker 1: this gpt thing was but it was difficult to set
Speaker 1: up at the time but then yeah you know i
Speaker 1: tried it and of course like everybody else was kind
Speaker 1: of blown away.
Speaker 2: Yeah Later that year in September is when Microsoft actually
Speaker 2: licenses GPT-3 from OpenAI, which I presume is how GitHub
Speaker 2: gets access to it. They'll make GitHub Copilot the following.
Speaker 2: A couple more stories. In November, Apple announces the M1 processor.
Speaker 1: Yes.
Speaker 2: And I mention this because this, I would argue, is
Speaker 2: Tim Cook's most memorable move. He was always a hardware guy.
Speaker 2: This is an astonishing piece of hardware. There's a system
Speaker 2: on a chip where the GPU and CPU, NPU, the
Speaker 2: IO and security buses and so forth are all literally
Speaker 2: in the same die. The memory is in the same package.
Speaker 2: So this is made by TSMC, five nanometer process, about
Speaker 2: 16 billion transistors total. That includes eight CPU cores, eight
Speaker 2: GPU cores, a 16 core neural engine, and up to
Speaker 2: 16 gigabytes of RAM right.
Speaker 1: On the package.
Speaker 2: So you get both lower power consumption and higher performance.
Speaker 2: And little would we realize.
Speaker 1: I have a MacBook Pro with an M1. Yeah. First gen.
Speaker 1: And it's good.
Speaker 3: Is that 16? Is that megabytes or gigabytes?
Speaker 1: Gigs.
Speaker 3: Yeah. That's RAM, RAM, not cache.
Speaker 2: That's RAM, RAM.
Speaker 3: Okay. Yeah.
Speaker 2: They're not putting cache on. The cache is there too.
Speaker 1: Okay.
Speaker 2: And also that RAM is shared with the GPU.
Speaker 1: Right.
Speaker 2: So what we're doing right now with LLMs and the
Speaker 2: new agent models and so forth, The M1 was built
Speaker 2: for it, not knowing it was built for it. They
Speaker 2: were just trying to make the most efficient computer they
Speaker 2: could consume the least power. And this is Apple's move
Speaker 2: back to ARM, having come from the Motorola chipset, moved
Speaker 2: to Intel for a few years. Now they're making their
Speaker 2: own thing based on ARM.
Speaker 1: Two more.
Speaker 2: December, both in December. The SolarWinds supply chain attack. So
Speaker 2: this is Russian SVR. The pure brilliance of this is unbelievable.
Speaker 2: So in September of 2019, hackers successfully break into the
Speaker 2: SolarWinds development environment and they insert code into the development chain.
Speaker 2: The way they do it is incredibly insidious. It's part
Speaker 2: of their build system that they replace code in the
Speaker 2: build without actually changing the visible source code. So developers
Speaker 2: don't think their code has changed at all, but what
Speaker 2: they're actually compiling is different code with this thing called
Speaker 2: the sunburst backdoor. They, they, they, It takes them a
Speaker 2: few months of doing testing to get this to work.
Speaker 2: By March, they have actually figured it out. And the
Speaker 2: Orion monitoring software, SolarWinds builds this infrastructure monitoring software, is
Speaker 2: now distributed to 18,000 customers with the Sunburst backdoor in it.
Speaker 2: The Russians are successful enough that in June, they actually
Speaker 2: removed the whole build injection system. Like, they're done. And
Speaker 2: are happily operating it. Now, admittedly, they don't actually use
Speaker 2: that backdoor much. Maybe 100 customers are totally affected. But
Speaker 2: it's in December when one of those customers, a security
Speaker 2: company called FireEye, realizes they've been exploited and traces it
Speaker 2: back to the Orion code base and basically pops the
Speaker 2: whole thing open. It's an incredibly sophisticated supply chain attack
Speaker 2: and scares just not actually everybody. It's not the first one,
Speaker 2: but in a lot of ways, it's the one that
Speaker 2: made the most news.
Speaker 1: It could be made into a feature film, actually, if
Speaker 1: it was handled correctly.
Speaker 2: It's astonishing.
Speaker 1: Yeah.
Speaker 2: And if the Russians hadn't decided to go after FireEye,
Speaker 2: who knows when it would have been detected. Just he
Speaker 2: went after the guys who were in the security space
Speaker 2: and good enough at attacking breach properly.
Speaker 3: Yeah, I remember when I was invited to a meeting
Speaker 3: to be briefed on the attack when we sort of
Speaker 3: knew what was going on. And yeah, I'll be frank,
Speaker 3: I was kind of gobsmacked actually by- Gobsmacked, yeah. By
Speaker 3: the sophistication.
Speaker 2: It's so clever. Holy man. I don't expect bad guys
Speaker 2: to be this smart, right? If they were smart, they'd
Speaker 2: be good guys. Like the idea that bad guys would
Speaker 2: come up with something this clever. But again, state actors,
Speaker 2: like they're working for more than just a paycheck here.
Speaker 3: Yeah, but remember though, you know, As Sherrod Dugripo has
Speaker 3: told me many, many times, this is their day job, right?
Speaker 3: They come to work, they clock in, they do the work,
Speaker 3: they have reviews every year, they go home to their families,
Speaker 3: and they start again tomorrow.
Speaker 2: They get promotions by figuring this stuff out.
Speaker 3: Exactly. It's just their job.
Speaker 1: Yeah. As Dwayne LaFleur would say, oh, this is awesome, guys.
Speaker 1: This is awesome. It's a stunner.
Speaker 2: I'll finish out the year of compute in 2020 with
Speaker 2: China's Zhuheng Photonic Quantum Computer, which I think is particularly
Speaker 2: relevant for today's conversation. This was a dedicated machine using
Speaker 2: photonic quantum entanglement, which is very, very clever, unique, very
Speaker 2: different from Sycamore, the Google's device from the previous year,
Speaker 2: which was the … The hanging chandelier in liquid helium,
Speaker 2: this doesn't need any of this, but it was built
Speaker 2: specifically for Gaussian boson sampling.
Speaker 1: Nobody knows what you're talking about, Richard. I'm okay with that.
Speaker 1: I might contest.
Speaker 3: I mean, I know enough to be dangerous. Talk to
Speaker 3: me about the software side of it.
Speaker 2: Yeah, and that's the whole thing is this is nowhere
Speaker 2: near a general purpose computer or even a supercomputer. This
Speaker 2: is a machine to demonstrate that quantum entanglement can tackle
Speaker 2: one kind of problem, the Gaussian boson sample problem. Now,
Speaker 2: that's an important problem, but it was sort of a
Speaker 2: proof point I think very much this is a, hey,
Speaker 2: we get to play too. And I think everybody reacted
Speaker 2: to it that way. Because this 200-second run for something
Speaker 2: that in theory would have taken this supercomputer 2 billion years,
Speaker 2: not that anybody's going to test that, it just put
Speaker 2: China instantly on the map and really made it very clear.
Speaker 2: There's more than one way to quantum. And this is
Speaker 2: a wildly different way. Not that we've heard much from
Speaker 2: them since. But in 2020, that was a really big deal.
Speaker 3: But does it run Doom?
Speaker 2: It really doesn't.
Speaker 1: No, not a bit. No, it won't.
Speaker 2: I mean, supercomputers are limited in their own way, too,
Speaker 2: as well. But this was literally built for one thing.
Speaker 2: This is like Turing's device for cracking Enigma. Good for
Speaker 2: one thing. The idea of general-purpose computing is a much
Speaker 2: different idea than what we're doing in this kind of
Speaker 2: class of work.
Speaker 1: Anyway.
Speaker 3: Yeah, 100%. I think people need to understand that. Yeah,
Speaker 3: still people don't grapple that. There won't be an office
Speaker 3: for quantum. It's not going to exist.
Speaker 1: Oh, man.
Speaker 3: I'm sorry.
Speaker 1: You sold me that subscription. Let's get them on the phone. Yeah.
Speaker 2: And as much as we can tell at this time,
Speaker 2: these will always be supercomputers for particular problem spaces. Most
Speaker 2: of them very deterministic problem spaces, too. But let's wrap
Speaker 2: up the history lesson and get on to our larger
Speaker 2: conversation about quantum.
Speaker 1: Well, but first, we have to do.
Speaker 2: But first.
Speaker 1: Better know a framework. Roll the music. Awesome.
Speaker 3: All right, man.
Speaker 4: What do you got?
Speaker 1: All right. So, as people who listen to me on
Speaker 1: my various podcasts and stuff probably know, I bought this
Speaker 1: big GPU machine. a year or so ago, just because
Speaker 1: I anticipated being able to run local models.
Speaker 2: And you got it ahead of the hardware crisis too.
Speaker 2: So how smart are you?
Speaker 3: Yeah.
Speaker 1: I got it at walmart.com for $ 6, 000. It uses an
Speaker 1: NVIDIA RTX 1590 with 32 gigs of VRAM.
Speaker 2: Today that card's 15 grand if you can find one.
Speaker 1: I have, yeah, now it is. I have 96 gigs
Speaker 1: of system RAM and it's You know, blinky lights and
Speaker 1: quiet as anything, right? Which is amazing. So on Coded
Speaker 1: with AI, Jeff Fritz and I did a series on
Speaker 1: taking a whole bunch of models that would run on
Speaker 1: Ollama and running them and then putting it through a test. Basically,
Speaker 1: a lot of them failed. More so because of context,
Speaker 1: I think, than this is what I'm learning now, the
Speaker 1: context size, if it's too small. We'll just barf. The
Speaker 1: LLM will just and lose it or get into an
Speaker 1: infinite loop. And basically what I came down to is
Speaker 1: running llama.cpp. And llama.cpp is like Ollama, but it's not.
Speaker 1: It's a different thing. It's open source. But I can
Speaker 1: run the fairly new QEN 3.8.27b model and llama cpp
Speaker 1: will use vram and system ram at the same time
Speaker 1: and it will balance them out and figure out automatically
Speaker 1: how much of which to use and let me tell
Speaker 1: you something this is i this is what i've been
Speaker 1: waiting for it works so well that i don't feel
Speaker 1: the need to go back for what i do you
Speaker 1: know debugging coding all of that stuff i don't need
Speaker 1: to go back to any frontier models anymore.
Speaker 3: Right.
Speaker 1: I haven't found, I've been using it for a couple
Speaker 1: of weeks.
Speaker 2: You're just working local now.
Speaker 1: I'm just working local. Yeah. And the only thing I'm
Speaker 1: that's costing me is electricity. But I got solar panels.
Speaker 1: There you go. Some pretty good, especially in the summer.
Speaker 2: Feeling good. And that machine you bought, like to build
Speaker 2: that machine today, it's a big bucks.
Speaker 3: Yeah.
Speaker 1: So you did the right thing. Well, I thought it
Speaker 1: was big bucks back then, but now... Yeah, it was. Yeah.
Speaker 2: It was a lot of money for a PC back then.
Speaker 2: It doesn't seem that way at this moment.
Speaker 3: Well, anyway... And what sort of performance are you getting
Speaker 3: out of it? Like tokens per second?
Speaker 1: That's great. It's as good as... Any frontier model that
Speaker 1: I've been using, I've been using GitHub Copilot CLI, mostly
Speaker 1: with Claude Sonnet. It's as good as that. I don't
Speaker 1: find myself waiting around. And it can do anything that
Speaker 1: I throw at it. It handles local stuff on the computer,
Speaker 1: stuff in Azure, in GitHub. It's just really good. This
Speaker 1: model compared to other models is good, but you run
Speaker 1: it in Lama CPP. And it's like beautiful on this
Speaker 1: particular configuration. I've found the sweet spot. So I wrote
Speaker 1: a document and that is the link that we'll put
Speaker 1: on the page. It's a GitHub. Read me basically running
Speaker 1: Quinn 3.8, 27 B with Lama CPP and GitHub co-pilot
Speaker 1: CLI on windows. And it tells you exactly how to
Speaker 1: install everything, all the stuff that you got to go,
Speaker 1: put everything where it needs to go. And like, Download
Speaker 1: Quinn and run it and how you access it remotely.
Speaker 1: It's great. So I have my dev machine. I have
Speaker 1: my GPU machine. And it's a match made in heaven.
Speaker 2: There's not a lot of people running those kinds of
Speaker 2: headless systems with Windows.
Speaker 1: They're mostly Linux.
Speaker 3: Right.
Speaker 1: Cool. It's good. And also, this model, Quinn 3.8, has
Speaker 1: vision support. So I can paste screenshots in, you know,
Speaker 1: and it just works. It's wonderful. Cool.
Speaker 4: Yep.
Speaker 1: That's what I got. Richard, who's talking to us?
Speaker 2: Grabbed a comment off of show 1963, which you did
Speaker 2: last year with one Michael Howard.
Speaker 3: Yay.
Speaker 2: Talking about 30 years of application security. This is back
Speaker 2: when you were still the red teamer. I know your
Speaker 2: life is different now. And this comment comes from also
Speaker 2: a past guest, Arnold Axelrod, who said, great show as always.
Speaker 2: One comment regarding input validation, because of course we talked
Speaker 2: about input validations. Toward the end of the show, Michael
Speaker 2: mentions that all input should be considered evil and must
Speaker 2: be validated in order to be considered secure. Yeah, hard
Speaker 2: to argue with that. I'm not a security expert, but
Speaker 2: I have a different take on that. I don't think
Speaker 2: that the problem lies in the lack of input validation,
Speaker 2: but I think that input validation should be a business requirement.
Speaker 2: The example being zip codes. I don't necessarily know what
Speaker 2: a formal zip code is or will ever be consistent
Speaker 2: around the world. Answer is absolutely no. When you consider
Speaker 2: the idea that Ireland only got postal codes in 2015,
Speaker 2: like good luck. In my opinion, the problem lies with
Speaker 2: the use of parsers and interpreters and not using escape
Speaker 2: sequences or other structures to separate arbitrary input from structure ones,
Speaker 2: like separating the inputs from the SQL statement itself appropriately.
Speaker 2: Both SQL, JavaScript, and command through the process start in
Speaker 2: C-sharp are interpreters, and if you construct an input to
Speaker 2: them that contains an arbitrary user input without sanitizing it
Speaker 2: with the correct escape sequences is where unpredictability comes to play,
Speaker 2: which causes the risk. A URI also having structured format
Speaker 2: that is parsed by a browser and constructing a URI,
Speaker 2: let's say, with an arbitrary query string, that may be harmful,
Speaker 2: but you're probably using URI encoding on the inputs, and
Speaker 2: that should leave you safe. This doesn't require you to
Speaker 2: limit the input in any way, just to format it correctly.
Speaker 2: There is where the focus should be, as far as
Speaker 2: I'm concerned, not just to invalidate all inputs. I'd love
Speaker 2: to hear your opinions on it.
Speaker 3: You want my opinion?
Speaker 1: Go for it. Yeah, hit you.
Speaker 3: You know, it all got turned on its head, right?
Speaker 3: With LLMs and jailbreaking. What is the input? What is it?
Speaker 3: What is valid? Can you even escape it? Even escape
Speaker 3: versions can still get through any kind of checks. So, yeah,
Speaker 3: I just wrote about that recently. Yeah.
Speaker 2: Our new injection attack starts with ignore all previous instructions.
Speaker 3: Exactly. So, Mike Resinovich actually has a t-shirt with that
Speaker 3: on the back. He showed it to me at Build
Speaker 3: last time and I almost fell over laughing.
Speaker 1: It's the best.
Speaker 3: He was so proud of it. He said, hey, Michael,
Speaker 3: check this out. It's completely turned on its head. And
Speaker 3: that's why we've got all these other defenses that come
Speaker 3: into play and these guardrails and so on in LLMs.
Speaker 3: It's because we need them. We don't know what the
Speaker 3: input is.
Speaker 1: Yeah. LLMs need to get a sense of humor, right?
Speaker 1: A sense of sarcasm, a sense of irony. And they
Speaker 1: got to get sensitive to that just like we humans do.
Speaker 1: I think.
Speaker 3: I don't know.
Speaker 2: Yeah, we really want to pass every input through an
Speaker 2: LLM to say, is this a potential attack?
Speaker 1: Yeah, good luck with that. No, but of course not.
Speaker 1: But I mean, if you're dealing with an LLM and
Speaker 1: you're at the keyboard and talking to it, right? And
Speaker 1: you give it some ridiculous prompt, you know, that's clearly
Speaker 1: satirical or something. It should laugh back at you, you know?
Speaker 3: Well, that happened to me once.
Speaker 1: Yeah, that's a good one. Yeah.
Speaker 3: Dude, that happened to me once. All seriousness.
Speaker 2: Really?
Speaker 1: Yeah.
Speaker 3: I was working on the podcast website or something and
Speaker 3: asked it to do a quick security review of the code.
Speaker 3: And it found something. I was just running Visual Studio,
Speaker 3: I think. And it found something and it said, here
Speaker 3: is a, I don't know, it was an outdated HTTP header.
Speaker 3: It had been deprecated. I didn't know. A supposedly security
Speaker 3: header had been deprecated. And it said, by the way,
Speaker 3: this HTTP underscore blah, blah, blah has been deprecated for
Speaker 3: security reasons. And it's really ironic that you as the
Speaker 3: author of Running Secure Code didn't find this.
Speaker 1: Oh, that's great.
Speaker 3: Yeah.
Speaker 1: That's what I'm talking about.
Speaker 3: I don't know what the backend model was because, of course,
Speaker 3: Visual Studio, you can jump around, but I don't know.
Speaker 3: But yeah, it was quite happy to yell at me
Speaker 3: and laugh at me.
Speaker 1: That's pretty good.
Speaker 2: When the tool says the word, it is trying to
Speaker 2: detect irony. That's just ironic, actually.
Speaker 3: Right.
Speaker 1: Yeah.
Speaker 2: It's very recursive. Arnon, thank you so much for your comment.
Speaker 2: And a copy of Music to Code By is on
Speaker 2: its way to you. And if you'd like a copy
Speaker 2: of Music to Code By, write a comment on the
Speaker 2: website at. netrocks. com or on the Facebooks we publish every
Speaker 2: show there. And if you comment there and I read
Speaker 2: it on the show, we'll send you a copy of
Speaker 2: Music to Code By.
Speaker 1: Or if you'd just rather buy Music to Code By,
Speaker 1: go to musictocodeby.net. You can get the tracks in MP3, WAV,
Speaker 1: and FLAC formats. Well, before we introduce Michael... Let's take
Speaker 1: a little break for these very important messages. And we're back..
Speaker 1: NET Rocks. I'm Carl Franklin. That's Richard Campbell. Hey. And
Speaker 1: that's Michael Howard. Let me introduce him formally. Your bio
Speaker 1: has changed a little bit. Michael Howard's been at Microsoft
Speaker 1: since 1992.
Speaker 2: Wow.
Speaker 1: Always in some form of security, IIS, SDL, the founder
Speaker 1: of SDL?
Speaker 3: Well, he's one of the guys that worked on the very,
Speaker 3: very earliest versions. It was like two or three of us, yeah,
Speaker 3: back in the day.
Speaker 1: Awesome.
Speaker 2: And that was the security lifecycle?
Speaker 3: Security development lifecycle, yeah. Back in the earliest, like, 2004.
Speaker 1: Also uh you worked in azure data on the red
Speaker 1: team last time we talked and now you're in post
Speaker 1: quantum crypto.
Speaker 3: Woohoo yeah baby Man, I'm happy to be here, too.
Speaker 3: It's a lot of fun.
Speaker 1: I mean, how can you have post-quantum if we haven't
Speaker 1: had quantum?
Speaker 3: Because the real attacks start post-quantum. That's the reason why.
Speaker 1: Yeah, you're right. I get it. You need to be ready.
Speaker 3: For certain things. Certain things, maybe not. But we can
Speaker 3: discuss that later.
Speaker 1: But yeah. Well, what does it mean, post-quantum crypto?
Speaker 3: Well, you think of things in three ways. This is
Speaker 3: the way we think about it at Microsoft. Anyway, I'm
Speaker 3: sure most of the industry does. um, data, data in transit,
Speaker 3: data at rest, and then cryptographic trust. So data on
Speaker 3: the wire, you know, stuff flying across the internet is
Speaker 3: probably protected by TLS today, more than likely perhaps SSH,
Speaker 3: but certainly TLS data at rest is encrypted most of
Speaker 3: the time or should be. And those encryption keys are
Speaker 3: wrapped with other keys, uh, key wrapping keys. And then
Speaker 3: you've got cryptographic trust, which is, you know, signatures, certificates,
Speaker 3: all that sort of good stuff. Um, The real threat
Speaker 3: is dead on the wire is being, you know, being
Speaker 3: pulloined as it flies across the wire.
Speaker 1: Yeah.
Speaker 3: And then when a quantum computer comes out in the future,
Speaker 3: that stuff can be broken. And the breaking aspect is
Speaker 3: essentially just breaking the RSA or the elliptic curve wrapping...
Speaker 3: that goes on and out pops the AES key that's
Speaker 3: used for the bulk encryption, and now you just decrypt everything.
Speaker 3: And in the case of data at rest, it's the
Speaker 3: key wrapping keys, right? They can be broken because they usually,
Speaker 3: for example, RSA, which can be broken with an algorithm
Speaker 3: called Shor's algorithm, S-H-O-R.
Speaker 1: Yeah.
Speaker 3: And it basically finds periodicity in the way those algorithms work.
Speaker 3: That's what it takes advantage of.
Speaker 1: Are our logs at risk for being pilfered by cryptos?
Speaker 3: Post-mortem crypto? I mean, if it contains sensitive data, which
Speaker 3: you shouldn't be logging sensitive data, right? No, no, no.
Speaker 1: But even if it wasn't containing sensitive data, is that
Speaker 1: something because it can go through so much data so
Speaker 1: fast that it could.
Speaker 3: I mean, if I had to prioritize stuff, I would
Speaker 3: focus on the actual data itself.
Speaker 1: Yeah, okay. So data in transit and then real data
Speaker 1: in your databases.
Speaker 3: Correct. Yeah. And then those, again, they can be snaffled.
Speaker 3: today and then once a quantum computer is made available and.
Speaker 1: That's where a lot of did you say snaffled.
Speaker 3: Are stolen snaffled purloined.
Speaker 1: Snaffled that's a good british.
Speaker 3: Word snaffled yeah um there's actually a real word i
Speaker 3: don't even know is it a real.
Speaker 1: Word it doesn't matter i i don't know but i
Speaker 1: never heard it.
Speaker 3: Before it is now there you go things you.
Speaker 1: Learn on dot numrocks all right It's all good.
Speaker 3: Yeah, so the risk is the asymmetric keys that are
Speaker 3: used to wrap the symmetric keys that do the- Because
Speaker 3: they're dependent on prime numbers. In the case of RSA.
Speaker 1: Yeah.
Speaker 3: But that's not the attack. The attack is the periodicity.
Speaker 3: There's a periodicity. If you actually look at the way
Speaker 3: Shor's works, not that I say, not that you should,
Speaker 3: it basically does a quantum fast Fourier analysis.
Speaker 1: Yeah.
Speaker 3: Shor's is actually hybrid. It's actually quantum and sort of,
Speaker 3: classic computing. The hard work is done by Shor's and
Speaker 3: then some of the less difficult work is done classically
Speaker 3: because it's just easier. And so the real issue is
Speaker 3: that those asymmetric keys, RSA, elliptic curve, Diffie-Hellman, they all
Speaker 3: exhibit some periodicity that can be detected by Shor's. And
Speaker 3: that gives you a whole bunch of possibilities that then
Speaker 3: classical computing can then just sort of sift through and
Speaker 3: find out which ones are the actual keys. Right.
Speaker 2: So it narrows the scope of the testing needed.
Speaker 3: Correct. Yeah. And to your point before, rather than, you know,
Speaker 3: squillions of ages of the universe, it could be hours
Speaker 3: or days. Yeah.
Speaker 1: Right.
Speaker 3: You know, it's, it's, it's a real thing. And, um,
Speaker 3: you know, developers have a big part to play in,
Speaker 3: in this. It's not just, you know, flip some switch
Speaker 3: and everything's golden. Um, There's a lot more to it
Speaker 3: that developers need to understand as well.
Speaker 1: So everything I've barely hung on understanding about quantum is
Speaker 1: that we're all screwed, right? And because of the way
Speaker 1: that TLS works and SSL and all that stuff, it
Speaker 1: dramatically has to change, doesn't it? If we're going to
Speaker 1: be less susceptible to quantum interference but you're i think
Speaker 1: what you're saying is that there are ways that we
Speaker 1: can do that now and that's what you know post-quantum
Speaker 1: crypto is all about is trying to use cryptographic methods
Speaker 1: now that will survive the quantum onslaught is that what
Speaker 1: you're basically up against yeah one.
Speaker 3: Of the beauties of tls by the way i can't
Speaker 3: believe you said ssl like wash your mouth out.
Speaker 2: You know, some of us were around in the 90s.
Speaker 1: So was I. And so they don't use those words, TLS.
Speaker 3: I know. Anyway, I'll just pretend you didn't say that. Yeah,
Speaker 3: so TLS, one of the beauties of TLS is that
Speaker 3: it's very agile, right? You can change the way it works,
Speaker 3: the ciphers that are used, the cryptographic primitives that are used.
Speaker 2: And you're talking about TLS 1.0.
Speaker 3: Correct. So TLS 1.2 should be using.
Speaker 1: Yeah.
Speaker 3: So actually that's a really important point. So TLS 1.2
Speaker 3: and prior, so TLS 1.0 and 1.1 are deprecated anyway,
Speaker 3: so don't use them. TLS 1.2 does its cipher suite
Speaker 3: and its key establishments and authentication all as one string
Speaker 3: called the cipher suite. It looks like someone sneezed on
Speaker 3: the screen basically. It's a list of all the algorithms
Speaker 3: that are used for all of those things. TLS 1.3
Speaker 3: is different. it broke apart things like the key establishment
Speaker 3: from the bulk encryption and the bulk tamper detection. They're
Speaker 3: completely broken apart.
Speaker 1: Yeah.
Speaker 3: So you can negotiate the two separately. That's the big
Speaker 3: difference in TLS 1.3. So the key establishment is a
Speaker 3: thing called a group. And the reason why it's called
Speaker 3: a group is because mathematicians got to hang on this.
Speaker 3: And they said, you know, all these things are mathematical groups.
Speaker 3: So we'll call them groups. Terrible name. But for the
Speaker 3: key establishment, that's where you set the algorithm or algorithms
Speaker 3: in some cases. And then after that, separately, is how
Speaker 3: you do bulk protection of the data on the wire.
Speaker 3: So TLS 1.3 broke those two apart. So it is
Speaker 3: completely not compatible with TLS 1.2. And TLS 1.2 will
Speaker 3: never be post-quantum. I mean, it's just software. I mean, essentially,
Speaker 3: I suppose it could make it post-quantum.
Speaker 2: Yeah, but why would you?
Speaker 3: But the interoperability... well, the interoperability story would be horrendous.
Speaker 3: Like no one would do it.
Speaker 2: But it also seems unnecessary too, right? Because I set
Speaker 2: the TLS 1.3 with a dropdown in Azure.
Speaker 3: Right. But the thing is, here's the issue. And this
Speaker 3: is one thing that we're having to work on for
Speaker 3: products like Front Door, for example, is you will be
Speaker 3: able to control the group, not just the bulk cryptography
Speaker 3: that's used.
Speaker 1: Okay.
Speaker 3: And that's where, and the group is where the post-quantum
Speaker 3: part comes in. For the most part, symmetric stuff AES-256, SHA-384,
Speaker 3: and so on, which are the baselines, are fine. There's
Speaker 3: another algorithm there called Grover's, which is an attack against
Speaker 3: symmetric algorithms. And it essentially cuts the number of bits
Speaker 3: in the key in half. So if you have an
Speaker 3: AES-256 in a quantum world, that's the same as AES-128. Interesting.
Speaker 1: Which is fine.
Speaker 3: So you must use AES-256 and SHA-384 as the minimum
Speaker 3: as well. They're kind of okay.
Speaker 1: They're fine.
Speaker 3: The problem is the asymmetric stuff. Right. Yeah. Elliptic curve, RSA, Diffie-Hellman.
Speaker 3: That's where the problem is. Now, the nice thing in
Speaker 3: TLS 1.3 is that's defined in a group, and that's
Speaker 3: negotiated separately from the bulk cryptography. And that's where the
Speaker 3: hybrid algorithms come into play. And the reason why they're
Speaker 3: called hybrid is you use two together. You use elliptic
Speaker 3: curve and MLChem. So MLChem is the quantum resilient algorithm.
Speaker 3: Elliptic curve is classic. you build up keys in both,
Speaker 3: you smush them together, pass it through a hash, and
Speaker 3: then you derive the session keys after that. So they're
Speaker 3: both used together.
Speaker 1: So that would have to be implemented both at the
Speaker 1: browser level and at the server level, right?
Speaker 3: Yeah, everywhere. I mean, you say browser, but client. I mean,
Speaker 3: I just mean clients in general.
Speaker 1: Yeah, clients, sure.
Speaker 3: And in fact, you bring up a very important point there, Carl,
Speaker 3: and that is that all modern browsers support hybrid TLS 1.3.
Speaker 1: Yeah.
Speaker 3: So the, I mean, even the humble Xbox has hybrid.
Speaker 3: I've tried all sorts of, you know, iOS, Android, Windows, Mac, Linux,
Speaker 3: and all the common browsers support.
Speaker 1: So anything, anything that uses it like curl or any,
Speaker 1: any little command line tool, all, all those things have
Speaker 1: to support it.
Speaker 3: Correct. Correct. So SSH, both client server supports it as
Speaker 3: a version 10, I think maybe 9.9 or 10. supports
Speaker 3: um ml chem so the the important part there in
Speaker 3: the in ml chem is the letter l in that
Speaker 3: there's lattice and the two major algorithms that are post
Speaker 3: quantum resilient there's actually a small number but the two
Speaker 3: major ones ml chem and ml dsa the l is
Speaker 3: lattice and the is that lattice construct that is quantum resilient.
Speaker 1: Right so when you say quantum resilient do you mean
Speaker 1: what you perceive as the first generation of quantum or
Speaker 1: all quantum going forward till the end of time?
Speaker 3: Nah, I mean, NIST is still going through other algorithms.
Speaker 3: The industry has settled, and NIST has settled on MLDSA
Speaker 3: and MLChem. And there's been a lot of research for
Speaker 3: the last 20-something years in lattices, looking at it through
Speaker 3: a quantum lens, and they look good. but everyone's you
Speaker 3: know quite happy to say let's you know let's go
Speaker 3: look at other algorithms as well just in case and
Speaker 3: in fact for no other reason than the resulting cipher
Speaker 3: blob is big so i'll give you an example If
Speaker 3: you have an elliptic curve, say an EC25519, which is
Speaker 3: a curve, the signature, a digital signature for that is
Speaker 3: 64 bytes in size. It's pretty small. If you take
Speaker 3: an MLDSA87 certificate and you sign data with the private
Speaker 3: key of that, it's about 4.5K. So you imagine if
Speaker 3: you've got a whole series of certificates all with their signatures...
Speaker 3: it adds up real quick.
Speaker 1: Yeah.
Speaker 3: And you can have problems with MTUs, with people passing
Speaker 3: stuff on query strings, amounts of space set aside on
Speaker 3: disk for signatures, you know? Yeah, so it's a real issue.
Speaker 3: So NIST is continuing to evaluate other algorithms with an
Speaker 3: eye to potentially smaller signatures. So now I get.
Speaker 1: Why it's called Lattice because it kind of makes a
Speaker 1: web of data that's hard to penetrate. Is that good analysis?
Speaker 3: No, it's terrible.
Speaker 1: Terrible. It's terrible.
Speaker 3: I can take it. Okay, here's how lattices... I claim stupidity.
Speaker 3: It's all good, mate. So, the way lattices work, and
Speaker 3: this is a terrible description, but it's an interesting way
Speaker 3: of thinking about it.
Speaker 1: It'll be better than mine, I guarantee it.
Speaker 3: I may not be. I'm not a fan of analogies,
Speaker 3: so here's an analogy for you.
Speaker 1: Okay.
Speaker 3: Imagine a chessboard, right? Eight by eight with a knight.
Speaker 3: We know the knight moves either one and two or
Speaker 3: two and one, right?
Speaker 1: That's all it does.
Speaker 3: Yeah. If I give you an end point and I
Speaker 3: give you a starting point, what route does the knight
Speaker 3: take to get there? That's pretty straightforward to do, you know,
Speaker 3: because it's just eight by eight. Now, imagine if that
Speaker 3: was a squillion by a squillion chessboard. Right. All right.
Speaker 1: Got it.
Speaker 3: Oh, no. You know, it gets harder. Now, imagine it's
Speaker 3: a thousand dimensions, right? Now imagine I don't tell you
Speaker 3: there's one by two, it's N by M.
Speaker 1: Right, okay.
Speaker 3: Now, just to make things even more difficult, it's not
Speaker 3: like an air quotes square chessboard. The squares are kind
Speaker 3: of funky shaped. They're not quite squares. And that's a
Speaker 3: thing called learning with errors. So that's hard. Here's a
Speaker 3: point somewhere in this N dimensional space. Here's your starting point.
Speaker 3: How do you get there? And so essentially the N
Speaker 3: by M is essentially like the private key. That's one
Speaker 3: way of looking at it. Terrible analogy, but it's about
Speaker 3: as close as you can get without introducing math.
Speaker 1: Okay.
Speaker 3: Yeah.
Speaker 1: All right. Good. And so you don't think that quantum
Speaker 1: computers could ever get so good that they could just
Speaker 1: figure that stuff out quickly?
Speaker 3: You mean when you throw in some AI as well? Yeah. Yeah.
Speaker 3: Go on.
Speaker 2: But nobody ever comes up and thinks, hey, we've solved cryptography.
Speaker 2: You're always looking at new algorithms. You're always looking at
Speaker 2: new key lengths. We expect to routinely replace our algorithms.
Speaker 1: It's an arms race.
Speaker 2: Because the bad guys are fighting back.
Speaker 3: Which is a beautiful segue into the next topic, which
Speaker 3: is crypto agility. If nothing else, from a developer perspective,
Speaker 3: one thing that post-quantum crypto will bring to the table
Speaker 3: is the need for crypto agility. what happens if you
Speaker 3: wrap some keys in MLChem? Chem stands for key encapsulation method.
Speaker 3: Let's say you wrap some keys in that and it
Speaker 3: ends up being broken five years, 10 years from now.
Speaker 3: How can you update your application to use a new
Speaker 3: wrapping method without breaking your existing, like you can still
Speaker 3: read your old data, but you would write out using
Speaker 3: some MLChem + + or something. Right. And crypto agility
Speaker 3: is just, so important. It's really brought it to the
Speaker 3: forefront as a need, because we don't know long-term if
Speaker 3: these things will be successful or not. And again, to
Speaker 3: your point, Carl, cryptographers are very, very conservative when it
Speaker 3: comes to these sorts of things, and they want to
Speaker 3: have a big security buffer, knowing that some things will
Speaker 3: start to potentially creak a little bit.
Speaker 2: And of course, you're immediately going to the at-rest encryption problem.
Speaker 2: I'm always thinking TLS, and it's just we handshake an
Speaker 2: encrypted stream, we do our thing and then it disappears again.
Speaker 2: And so I don't have the, other than the, you know,
Speaker 2: harvest and decrypt later, I don't have to think about this.
Speaker 2: It's all transitory. We'll just use the newest algorithm. But
Speaker 2: if you've stored under an older algorithm, And now it's
Speaker 2: been breached. You have to decrypt, recrypt, or at least,
Speaker 2: you know, decrypt over time to get by that.
Speaker 1: You may have to increase the data size of your
Speaker 1: fields that take those things because it's going to take more. Yeah.
Speaker 3: So you've got to assume that there will be change.
Speaker 3: And unfortunately, a lot of people don't know how to
Speaker 3: build crypto agile solutions. It kind of drives me a
Speaker 3: bit bonkers, to be honest with you. I see, you know,
Speaker 3: in the press, you know, we need crypto agility. I've
Speaker 3: got to do crypto agility. Yeah. hey, crypto agility is
Speaker 3: really important. Are you guys doing crypto agility?
Speaker 2: Because it comes in a squirt bottle and you just
Speaker 2: spray it on all your devs and you'll be good.
Speaker 3: I know, but no one says how to do it.
Speaker 3: To me at Microsoft, there's two canonical examples of crypto agility.
Speaker 3: One is as a SQL DB or SQL server with
Speaker 3: always encrypted. And then the other one is the open
Speaker 3: office XML file format, which you use to encrypt documents
Speaker 3: in office. So the way it works in as a
Speaker 3: SQL DB, which to me is a beautiful and simple
Speaker 3: way of doing it. It's also very, very fast. If
Speaker 3: you ever look at the ciphertext in an always encrypted cell,
Speaker 3: the first byte is always a one, and that's the
Speaker 3: version number. And that basically means AES-256 cipherblockchaining with a
Speaker 3: SHA-256 hash as an integrity check over the data. So
Speaker 3: in the future, if they decide to upgrade it to
Speaker 3: something else, then that could be version two. So the
Speaker 3: first bike would be a two and they could always
Speaker 3: read back and say, okay, that's version one. We need
Speaker 3: this particular set of cipher primitives. Let's read as decrypted
Speaker 3: with these primitives. When they write it back, they would
Speaker 3: write it back as a, whatever the latest number was,
Speaker 3: which we version two, and it will be the, whatever
Speaker 3: the new, the new cipher suites is. So you can
Speaker 3: always read the old data and you would write back
Speaker 3: using the new version. And the way office does it
Speaker 3: is it's an XML file. There's an XML file header.
Speaker 3: And it contains all the cryptographic primitives, like AES, it's
Speaker 3: cipher blockchaining, here's the initialization vector, here's the password, the
Speaker 3: key derivation count, here's the key derivation algorithm, and lots
Speaker 3: of other metadata. So you can actually build the cipher
Speaker 3: collection completely dynamically, which is really, really nice.
Speaker 1: What network hardware will have to change in the, yes.
Speaker 1: I mean, we won't, we'll be able to go to
Speaker 1: Best Buy or whatever it is you have in the
Speaker 1: UK and buy an off the shelf, you know, router
Speaker 1: that is crypto happy. Oh, I mean, in theory, I
Speaker 1: think a lot of quantum happy rather.
Speaker 3: I mean, unless they're doing some kind of inspection, if
Speaker 3: they're just like passing data on, there should be no
Speaker 3: need for it, right? They're not decrypting stuff, but if
Speaker 3: they are decrypting stuff, then yeah, they're going to have
Speaker 3: to have access to these algorithms. If you're doing, you know,
Speaker 3: TLS termination, then yeah, for sure.
Speaker 2: The other that's not something you'll have in your home
Speaker 2: i did that stuff in racks of computers for companies
Speaker 2: but ah but.
Speaker 3: There's a fly in the ointment there's a huge fly
Speaker 3: in the ointment though and that is your laptop and
Speaker 3: your computer with tpms and trusted boots and that sort
Speaker 3: of stuff right right now those keys are probably rsa
Speaker 3: and well they are rsa or elliptic curve.
Speaker 2: They are and we're just going through the secure boot
Speaker 2: crisis thanks very much right.
Speaker 3: So that will all get that will all get busted
Speaker 3: and um you know so the hardware industry out there
Speaker 3: We're being mean here, Michael.
Speaker 1: Richard's squinting, but I think you've got to look at
Speaker 1: it like this. Hey, you've got to buy a new laptop.
Speaker 1: That's not a bad thing.
Speaker 2: But it's also like we're fixing keys all the time.
Speaker 2: These are BIOS updates. This will come in firmware.
Speaker 1: You think? There'll be new drivers.
Speaker 2: And they might be slower than a hardware-dedicated version of it,
Speaker 2: but I just don't feel– a lot of the stuff
Speaker 2: you're describing here, Michael, to me sounds like configuration settings
Speaker 2: in Azure. you've already done the work in the browser. Like,
Speaker 2: as long as I haven't done anything stupid in code,
Speaker 2: I don't think I have to do anything as a
Speaker 2: web dev.
Speaker 3: That's correct. 100% correct.
Speaker 2: I just got to make sure that my admins have
Speaker 2: set stuff right.
Speaker 1: Well, if you're using IIS, you're going to have to
Speaker 1: make sure you're in the latest version that supports it.
Speaker 1: But in Azure.
Speaker 3: Well, http.sys... So I actually wrote a blog post on
Speaker 3: this because about six-ish weeks ago, we released a version
Speaker 3: of S Channel, which is the Windows TLS stack that
Speaker 3: supports TLS 1.3 hybrid. And I wrote a dumb ASP.NET application,
Speaker 3: you know, dumber than a bucket of rocks just to
Speaker 3: keep it really, really simple and did no configuration whatsoever
Speaker 3: in the code. And that's a really important point. Like,
Speaker 3: you know, thou shalt not do any TLS configuration in code,
Speaker 3: like leave it to the OS or to some configuration
Speaker 3: somewhere else, definitely not in code. And yeah, I just
Speaker 3: turned on that. I wanted X35519 MLChem768 in priority zero.
Speaker 3: in the Cypher suite and group order. And I ran
Speaker 3: this application and I connected it, connected using a browser
Speaker 3: and I was living in the future.
Speaker 4: Nice.
Speaker 1: Michael, how long do we have before we need to
Speaker 1: configure things correctly?
Speaker 3: How long do we have? I mean, I mean, it
Speaker 3: depends on risk. I was talking to a large retailer.
Speaker 3: You know who they are, but I can't say who
Speaker 3: they are.
Speaker 1: Perfect.
Speaker 3: And they're not concerned.
Speaker 1: The one I bought my computer from?
Speaker 3: They're not concerned about right now anyway with their devices
Speaker 3: that they use for shop floor inventory management, right? Because
Speaker 3: it's just shop floor inventory management. It's not sensitive data.
Speaker 3: So their Android devices that they're using will never support post-quantum.
Speaker 3: They're okay with that. Now, their corporate systems that run
Speaker 3: HR and payroll and all that sort of stuff, yes,
Speaker 3: they do care. So how long do we have? I mean,
Speaker 3: the clock started now for certain types of data. Depends
Speaker 3: on the data. If you've got really sensitive data or
Speaker 3: data that must be secret for a long time, healthcare information,
Speaker 3: military secrets, intelligence, financial records in some cases, perhaps. I
Speaker 3: don't know. I'm not a regulatory person. You know, they
Speaker 3: have a time that they must maintain their secrecy. And
Speaker 3: that clock's already started. Because if we take a 2029,
Speaker 3: 2030 timeframe, that's only four years. It's not even four
Speaker 3: years away. Hmm.
Speaker 1: On the screen behind you, a sentence came up a
Speaker 1: little while ago. There's no such thing as low-risk data.
Speaker 1: But apparently this large retailer seems to think there is.
Speaker 3: I think it said no low-risk secrets.
Speaker 1: Oh, low-risk secrets. That's right. Yeah.
Speaker 3: Yeah. Low-risk secrets.
Speaker 2: Secret is secret.
Speaker 1: So, if it's a secret by default, it's by definition
Speaker 1: a risk.
Speaker 3: Well, a small, air quotes, small secret can lead to
Speaker 3: access to bigger secrets. Like a low credential, for example,
Speaker 3: it can lead to something like a key.
Speaker 1: Sure.
Speaker 3: Yeah.
Speaker 2: The old classic, I got your Wi-Fi password from your
Speaker 2: light bulb because you thought, well, it's just a light bulb.
Speaker 1: What are you going to do to me? Right.
Speaker 2: But the fact that I got chain attack, once I
Speaker 2: got into the wifi, there was a whole lot of
Speaker 2: other things that were there.
Speaker 3: Yeah. And that's why I put all my IOT stuff
Speaker 3: on his own virtual network is our own isolated.
Speaker 2: Oh, you're darn right. You do.
Speaker 1: Absolutely. Yeah.
Speaker 3: Yeah.
Speaker 2: But, uh, at the same time, you know, it's still,
Speaker 2: I'm still sorting through what do I have to code
Speaker 2: as a dev versus what I have to, uh, you know,
Speaker 2: what's going to come to me, uh, just by making
Speaker 2: sure we're using the latest bits. I love your info
Speaker 2: on always encrypted. It's like, hey, now I want to
Speaker 2: go talk to my DBA. And it's like, we're up
Speaker 2: on this version, right? Because we have all this encrypted
Speaker 2: and REST stuff, and you don't want a crisis. So
Speaker 2: if you're already running always encrypted in SQL, then we
Speaker 2: should be good. When the new algorithms are needed, they'll work.
Speaker 3: The big issue, and this is one thing that a
Speaker 3: lot of products at Microsoft are having to deal with,
Speaker 3: is the symmetric stuff's fine. It's the key wrapping that
Speaker 3: has to change. The beauty of it, though, is it's
Speaker 3: just the key wrapping. So if you have a 256-bit
Speaker 3: AES key, you just decrypt it or unwrap it using RSA,
Speaker 3: for example, and then you rewrap it using AES-KW. which
Speaker 3: managed HSM in Azure, and now Key Vault, actually, Key
Speaker 3: Vault Premium in public preview, supports AESKW key wrapping, which
Speaker 3: is post-quantum resilient.
Speaker 1: Yeah, go ahead.
Speaker 3: So there's two issues that I see developers need to really,
Speaker 3: really think about. The number one is please don't put
Speaker 3: any TLS anything in your code.
Speaker 2: Yeah, it'll hurt you later.
Speaker 3: Don't restrict protocol version. Don't restrict cipher suites. Don't do
Speaker 3: any of that. Just let it be configured completely outside
Speaker 3: of the application. That's number one. Number two is this
Speaker 3: whole crypto agility thing. If you've got crypto code with
Speaker 3: the algorithms hard-coded in the code.
Speaker 2: You're in trouble.
Speaker 3: And you're encrypting squeaky bytes of data... You know, you've
Speaker 3: got to update your code and probably can't read the
Speaker 3: old data. So now you've got, you know, it's just
Speaker 3: a mess. And that's where the whole crypto agility comes in.
Speaker 3: And honestly, if you haven't got crypto agility in place,
Speaker 3: there are patterns you can use to wrap existing non-crypto,
Speaker 3: crypto agile blobs into like some sort of crypto agile
Speaker 3: envelope that contains all the metadata.
Speaker 1: So Azure's really good about letting me know when I
Speaker 1: need to move off of some version of something and
Speaker 1: onto something else because it's being deprecated. Do you think
Speaker 1: that sometime in the future, we're going to get an
Speaker 1: Azure thing when we log into the portal that says, hey,
Speaker 1: you need to upgrade your whatever it is to be
Speaker 1: quantum happy. You think that's going to happen? Like, should
Speaker 1: I just leave it up to Azure to warn me
Speaker 1: about things like that? Or is there stuff that I
Speaker 1: need to do now?
Speaker 3: I think it depends. If you look at the shared
Speaker 3: responsibility model, that's where it really becomes important. Like if
Speaker 3: you've got a platform managed key to encrypt data, then
Speaker 3: we're going to take care of that, right? Because a
Speaker 3: platform managed key. But if you've got a customer managed key,
Speaker 3: which is basically a key wrapping key, then they'll probably
Speaker 3: look at, I can't predict the future, but my guess,
Speaker 3: just my guess, Is that there will be notifications to say, hey,
Speaker 3: you know, we've now got the ability in Azure, blah, blah, blah,
Speaker 3: to wrap your encryption keys in quantum resilient keys. Would
Speaker 3: you like to do this? Yeah. And click here. Yeah.
Speaker 2: And the consequence is going to be very likely that
Speaker 2: the data streams are going to get larger because the
Speaker 2: quantum resilient keys are bigger. But I don't know what
Speaker 2: other impacts I'm going to see.
Speaker 3: No, you shouldn't see it. No, because the only thing
Speaker 3: you're really changing is the key wrapping. Right. Which is,
Speaker 3: so if you've got a 256-bit AES key, you're going
Speaker 3: to wrap it in AES-KW. And in fact, it'll probably
Speaker 3: be smaller than RSA, to be honest with you. But
Speaker 3: if you wrap it in MLChem, it will be bigger.
Speaker 1: Right.
Speaker 3: Yeah, but it's just the key.
Speaker 1: It's just the key.
Speaker 3: Yeah, the data doesn't change.
Speaker 2: Am I even choosing that or I'm just configuring to
Speaker 2: allow this and it'll optimize itself?
Speaker 3: No, what do you mean? When do I have to
Speaker 3: make a decision about this, about the rewrap? Well, first
Speaker 3: of all, the nice thing is it's very low friction. Right. Very,
Speaker 3: very low friction. Like it's microseconds to do the work.
Speaker 3: You're not decrypting and re-encrypting petabytes of data.
Speaker 1: Right.
Speaker 3: So my guess is personally, as soon as it becomes available,
Speaker 3: I would just opt in and just re-wrap your keys.
Speaker 2: So I'm going to wait for your blog post and
Speaker 2: then I'm just going to switch this stuff on.
Speaker 3: No, we'll push it through Azure Update.
Speaker 1: Okay.
Speaker 3: I guess it'll be through the Azure Updates website.
Speaker 1: Yeah.
Speaker 3: Yeah. Yeah.
Speaker 1: Good. And is this imminent like in the next year?
Speaker 2: Yeah.
Speaker 1: Wow.
Speaker 3: It'll depend on the service. Yeah. So, so, so I
Speaker 3: really want to point something out here is that, you know,
Speaker 3: this post-quantum stuff is very layered, right? So the very
Speaker 3: bottom of the layer, you've got the algorithms. Well, that
Speaker 3: stuff's been in place in windows for.
Speaker 1: For ages.
Speaker 3: Um, we have called sim crypt available in windows, Linux
Speaker 3: and Mac hand optimized C code. Absolutely beautiful to read.
Speaker 3: It's so well written. Honestly, it really is. Then above that,
Speaker 3: you've got, um, say TLS 1.3 with hybrid, right? You
Speaker 3: open those floodgates because now people can use that stack.
Speaker 3: So basically on windows is to use the new S
Speaker 3: channel stack. And in the case of Linux use open
Speaker 3: SSL 3.5, um, which has ML chem built into it.
Speaker 3: So you've got those two options are now available to you. Um,
Speaker 3: so that's, that's the data in transit taken care of.
Speaker 3: And then the last one, which is incredibly important is
Speaker 3: the key wrapping. And we now have that in, in Azure.
Speaker 3: So managed HSM has had a key wrapping since day one. And, um,
Speaker 3: as your Key Vault now has it, ASKW. So what's
Speaker 3: going to happen is that's going to open these floodgates
Speaker 3: and there'll be a Cambrian explosion of services coming online
Speaker 3: right as they adopt. And look, it won't happen like overnight,
Speaker 3: because everyone's going to do testing, make sure it works,
Speaker 3: make sure it fails correctly and that sort of stuff.
Speaker 3: But Richard, to your point, next year, We'll see a
Speaker 3: lot of services rolling this out.
Speaker 1: Starting to switch over.
Speaker 2: But I also remember when we started switching up keys,
Speaker 2: when attacks got smarter and so forth, there was a
Speaker 2: period where we changed a number of times different flavors of, yes, SSL,
Speaker 2: and then into TLS. We are restarting this in some
Speaker 2: respects with these new cryptography. I've got to think. The
Speaker 2: first move we make may not stick for more than
Speaker 2: a year or two before it's like, hey, now we
Speaker 2: found some problems and you probably want to switch to this.
Speaker 2: I just remember going through this with AAS and a
Speaker 2: few others. Like, we've done this before. In some ways,
Speaker 2: we've gotten really lazy because it's worked so well for
Speaker 2: so long.
Speaker 3: Well, actually, it's worse than that. And that is that,
Speaker 3: so we've actually become really lazy because of RSA.
Speaker 1: Right.
Speaker 3: RSA is interesting. RSA can do all the crypto primitives. Right.
Speaker 3: It can do signing, it can do encryption and all
Speaker 3: that sort of stuff. Elliptic Curve and Diffie-Hellman cannot. They
Speaker 3: can't do everything. And so we've been used to, like
Speaker 3: you said before, Richard, I'm not trying to laugh at you,
Speaker 3: but he said, you know, prime numbers. Well, that's just
Speaker 3: an RSA thing. That's not an elliptic curve thing. Right.
Speaker 3: Because everyone thinks of RSA.
Speaker 1: Yeah.
Speaker 3: And RSA is this Swiss army knife. It does absolutely everything.
Speaker 1: Sure.
Speaker 3: And the problem is it does absolutely everything.
Speaker 2: Absolutely everything.
Speaker 3: Which means we've got to change it absolutely everywhere. Yeah.
Speaker 2: It went everywhere. Well, the other side of this was
Speaker 2: because compute, I remember when it was expensive to do encryption,
Speaker 2: where we literally had separate servers from the website for
Speaker 2: doing just the encrypted pages. It's okay, well, now you're
Speaker 2: going to take your shopping cart and start a payment
Speaker 2: cycle that needs to be asked to sell. Now, it
Speaker 2: was this big thing about moving the cart over to
Speaker 2: the other much more expensive dedicated stack for completing a transaction.
Speaker 2: Because encryption used to be so costly. You know, these
Speaker 2: days our CPUs are so damn fast. They're sitting around
Speaker 2: playing poker and smoking cigarettes waiting for something to do.
Speaker 2: So sure, encrypt everything. Who cares? RSA is fast.
Speaker 3: Well, the funny thing is that first of all, it's
Speaker 3: just the key wrapping and unwrapping part.
Speaker 1: Yeah.
Speaker 3: Let's just call it key establishment because there's all different
Speaker 3: ways of doing it.
Speaker 2: That's really what's going on.
Speaker 3: That's the expensive part because it's all asymmetric stuff. And Windows,
Speaker 3: I think it still exists. There used to be a
Speaker 3: registry key called modexp offload for modular exponentiation offload, which
Speaker 3: is a very expensive RSA operation. And there was a
Speaker 3: way you could actually set a DLL in there, a
Speaker 3: name for DLL. It would actually offload that work to
Speaker 3: a DLL, which was a shim into some hardware to
Speaker 3: actually do the modular exponentiation work. But we don't need
Speaker 3: any of that stuff anymore. You know, when I look
Speaker 3: at the work that... you know, as your front door
Speaker 3: have done, for example, they've done a whole bunch of
Speaker 3: analysis on performance and the performance is like just a
Speaker 3: couple of percent, you know, going from elliptic curve to
Speaker 3: elliptic curve plus ML, ML chem. And that's because of
Speaker 3: optimizations made in the library.
Speaker 1: Sure.
Speaker 2: I got to tell you, Michael, there's this weird dichotomy
Speaker 2: going on where it's like the catastrophizing of quantum destroying
Speaker 2: everything and the, oh, just touch this button, problem goes away.
Speaker 1: Yeah. Yeah. I'm feeling that too. You're right.
Speaker 3: I wish it was that simple.
Speaker 2: Yeah. I keep waiting for what's not the simple part.
Speaker 2: I mean, for me, it's the frontline dev.
Speaker 1: Right.
Speaker 2: I mean, the administrator in me is a little sticky
Speaker 2: in the shorts right now because this is all very scary. Like,
Speaker 2: I want to check everything. I don't want to be
Speaker 2: the guy who didn't do his homework.
Speaker 1: Right.
Speaker 2: But for the dev, unless you've done something dumb, I
Speaker 2: think you're good as long as your administrators are on it.
Speaker 3: As I mentioned before, the two big dumb things are
Speaker 3: baking in crypto algorithms into your code and not being crypto-natural.
Speaker 3: That's dumb thing number one. Dumb thing number two is
Speaker 3: if you hard code your TLS configuration.
Speaker 2: Right.
Speaker 3: You're right. Those are the two big ones. Let's just
Speaker 3: ignore compatibility for a moment. If you change a server
Speaker 3: to use TLS 1.3 hybrid and only hybrid, by the way,
Speaker 3: the reason why it's called hybrid is because you do
Speaker 3: elliptic curve and MLChem together. The keys are derived from both.
Speaker 3: That's why it's called hybrid. But if you do hybrid
Speaker 3: and the client doesn't talk hybrid for whatever, you got
Speaker 3: like a crusty old Java application or C sharp application
Speaker 3: written 15 years ago, it's probably not going to work.
Speaker 1: Yeah.
Speaker 2: And it's really a question of, is it going to
Speaker 2: fail with some grace to tell you what the hell's
Speaker 2: going on?
Speaker 3: Yeah.
Speaker 1: Right. Yeah.
Speaker 3: It says, don't understand this cipher suite and gives you
Speaker 3: a hex value. Yeah. Really useful.
Speaker 1: Yeah.
Speaker 2: Well, that's better than object not found.
Speaker 3: One of the best ones in office back in the
Speaker 3: day was out of memory.
Speaker 1: Yeah. Michael, tell us about your book.
Speaker 3: Oh, my new book, man.
Speaker 1: Yeah.
Speaker 3: So, I wrote this book with Sean Hernan, Lee Holmes,
Speaker 3: and Sherry DeGrippo. So, Sean and I have known each
Speaker 3: other for many, many years. He's a partner engineering manager
Speaker 3: in Azure Security. I've been around for a long time,
Speaker 3: got the utmost respect for Sean, great guy. Lee Holmes,
Speaker 3: he was the security guy in PowerShell.
Speaker 1: Yeah, he's been on the show before too.
Speaker 3: Yeah, my boy Lee, great guy.
Speaker 1: Yeah, he's a good man.
Speaker 3: He and I actually worked together in the earliest days
Speaker 3: of the SDL because when Monad, as it was back
Speaker 3: in the day, had to go through all its SDL checks,
Speaker 3: I was the.
Speaker 2: Precursor to PowerShell?
Speaker 3: To PowerShell, correct.
Speaker 1: Yeah.
Speaker 3: I was like the SDL contact for Monad. And so
Speaker 3: Lee and I got to know each other incredibly well.
Speaker 3: And he's also a partner engineer in Azure. And then
Speaker 3: Sherrod DeGrippo, she's actually left Microsoft now. She goes to
Speaker 3: Palo Alto Labs. She is easily one of the preeminent
Speaker 3: experts in the world on threat actors. She knows absolutely
Speaker 3: everything about threat actors. So the book is Threat-Driven Software Development.
Speaker 3: And basically what it is is looking at software development
Speaker 3: through the eyes of threat actors, like what do threat
Speaker 3: actors actually do?
Speaker 2: Mm-hmm.
Speaker 3: And every chapter starts off... So first of all, Sherrod
Speaker 3: has her own chapter at the beginning. But every chapter
Speaker 3: after that looks at the contents of that chapter through
Speaker 3: the lens of threat intel. So every chapter starts off
Speaker 3: with anywhere between half and two pages of threat intel perspective,
Speaker 3: where Sherrod gives it a whole bunch of color. And
Speaker 3: then Lee, myself, and Sean go through and sort of
Speaker 3: explain that particular topic in detail. And a lot of it's...
Speaker 3: A lot of it's not just, don't think of it
Speaker 3: like just security best practices.
Speaker 1: It's not.
Speaker 3: It's DevOps as well as it's operational security, AppSec, and
Speaker 3: also Threat Intel all sort of munched together into one book.
Speaker 1: Sounds good.
Speaker 3: Yeah, a lot of fun. I did one when I
Speaker 3: was in the red team. Funny thing is, so Mark
Speaker 3: Rasinovich wrote the forward. And my manager at the time,
Speaker 3: Craig Nelson, who's CVP of the red team, he said,
Speaker 3: oh man, I really love this book. I gave him
Speaker 3: draft to look at. Can I write a chapter? I'm like, well,
Speaker 3: why don't you write the afterword? I said, I've never
Speaker 3: had an afterword in a book. Why don't you write
Speaker 3: the afterword? So he did. Nine pages. But the afterword...
Speaker 3: The after chapter. Yeah, the after chapter. Look, I'm not
Speaker 3: trying to besmirch Craig at all. That afterword is absolutely brilliant.
Speaker 3: If you were to sum up the afterword in like
Speaker 3: one sentence or two words, it would be So what?
Speaker 3: And he does a really, really good job of answering.
Speaker 3: So what? Yeah. It's really good. Yeah.
Speaker 1: That's good. It's really cool. Michael, what can we say?
Speaker 1: It's been enlightening having you here and talking about all
Speaker 1: this crazy stuff that we barely understand. Well, I barely
Speaker 1: understand anyway, but I understand a little more thanks to you.
Speaker 1: So thank you very much.
Speaker 3: You're welcome. Thanks for having me on.
Speaker 1: Great show, friend. Thank you so much. And we'll talk
Speaker 1: to you next time on. NET Rocks!. NET Rocks!
Speaker 4: NET Rocks is brought to you by Franklin's Net and
Speaker 4: produced by Plop Studios, a full-service audio, video, and post-production
Speaker 4: facility located physically in New London, Connecticut, and, of course,
Speaker 4: in the cloud, online at pwop.com. Visit our website at dotnetrocks.com
Speaker 4: for RSS feeds, downloads, mobile apps, comments, and access to
Speaker 4: the full archives going back to show number one, recorded
Speaker 4: in September 2002.
Speaker 1: And make sure you check out our sponsors. They keep
Speaker 1: us in business. Now go write some code. See you
Speaker 1: next time.