Podcast
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Links
Follow Me
Follow Me
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Post-Quantum Cryptography: Rethinking Trust Before the Clock Runs Out with David Pollak
Play On
27 MAY • 2026
1 hr 24 min
Share:
The encryption underpinning modern civilization was never designed to last forever. It was designed to be computationally hard to break with the machines we had. Google’s research now points to 2029 as the year elliptic curve encryption becomes breakable using quantum computers, and the implications stretch far beyond HTTPS. I’m joined by David Pollak, known widely as dpp, a technologist with nearly five decades of experience and the founder of Spice Labs, to explore what post-quantum cryptography actually means, why the transition is harder than almost anyone is treating it, and what organizations need to start doing now before the window closes.
David’s career resists easy summary. He wrote nuclear bomb damage estimation systems for FEMA at the age of fourteen, built spreadsheet software for NeXT computers that beat Lotus out of the market with a three-person bootstrapped company, and spent years consulting at Twitter in 2008 when the site was failing under its own growth. His work there involved diagnosing the root cause of the fail whale, a subtle interaction between Ruby’s garbage collector and co-located memcached processes, and ultimately rewriting Twitter’s public timeline endpoint to reduce fifteen boxes of infrastructure down to one. From there he moved to Cisco working on enterprise firewalls, and the thread running through all of it was a recurring encounter with systems where security assumptions had quietly broken down at the infrastructure level, long before anyone noticed.
That thread eventually led to Spice Labs. The insight behind the company came from applying the same Merkle tree logic that Git uses for source code to post-build artifacts instead, creating a graph of hash values across open source and proprietary software to map what cryptography is actually being used and where. The distinction matters because most existing tools for cryptographic discovery rely on source code access or build manifests like Maven and Gradle files, which do not reflect what was actually compiled into a binary. Teams frequently copy cryptographic libraries directly into applications without declaring them anywhere. By working from the artifact itself rather than the recipe, Spice Labs can find what is actually running, including the dependencies nobody documented and the legacy code nobody owns anymore.
We go deep on why post-quantum cryptography is both an urgent and a genuinely difficult problem to solve. David walks through the mechanics of Shor’s algorithm, which uses quantum superposition to perform prime factorization at speeds that make current RSA and elliptic curve encryption trivially breakable at sufficient qubit counts. The engineering constraints around quantum coherence have kept the threat theoretical, but Google’s 2029 timeline and China’s demonstrated ability to break 50-bit RSA suggest the gap is closing faster than most people assumed. The replacement candidates, a family of lattice-based algorithms standardized by NIST, carry real tradeoffs: larger key sizes, heavier computation, and no hardware acceleration in current processors, which means every system running cryptographic operations today is looking at a performance regression when it migrates. David introduces the concept of crypto agility as the key architectural principle, defining algorithm choices in configuration rather than baking them into source code, so that future algorithm updates do not require deep rewrites across an entire stack.
What makes the transition genuinely hard is not the cryptography itself but the inventory. David draws a sharp contrast between the Y2K problem, which was bounded by physical mainframe leases and gave CIOs a finite list of systems to audit, and today’s environment of millions of microservices, continuous delivery pipelines, and artifacts spread across cloud infrastructure with no central registry. The discovery problem is compounded by misaligned authority: CISOs and CIOs are responsible for certifying compliance but cannot require every engineering team to install a source-code scanning tool. The more tractable path is inspecting artifacts at the registry level, identifying which of twenty thousand microservices are performing digital signing operations, and narrowing the remediation conversation to a manageable scope. For legacy systems, whether COBOL on a mainframe or Java 5 code built on deprecated Sun classes, the options are proxying behind a quantum-safe layer or scoping a rewrite, and David is direct that AI-assisted migration is only credible where test coverage exists to validate the output. The organizational reality is that hardware roots of trust, including the HSMs and TPMs backing certificate authorities and device signing infrastructure, are almost entirely built on classical PKI and are not quantum-safe. Even AWS, which David describes as taking this more seriously than most, has set an internal deadline of 2028.
For engineers and security teams, this episode reframes the post-quantum cryptography transition as a discovery and prioritization problem before it is a remediation problem. The organizations that begin mapping their cryptographic surface area now, identifying where digital signing, at-rest encryption, and key management are actually happening across their software estate, will have the lead time to plan. The ones that treat this as a future problem will find themselves scrambling to remediate under pressure, with a deadline set not by a compliance framework but by the pace of quantum hardware development.
Links
Transcript
Show/Hide Transcript
Welcome back to another episode of Nerding Out With Viktor.
Today I'm joined by David Pollak and today is going to be all about post quantum crypto.
So nightmare fuel right there, David, for those not familiar with you.
I mean, we've spoken a bit of time over the last few weeks, but you want to do a quick intro to the audience like, who's David?
What should we know before we dive into all this terrifying stuff that we've been speaking about?
Hi, I'm David, otherwise known as dpp.
Been doing tech professionally for, I don't know, very long time.
47, 48 Years.
Got my start writing nuclear bomb damage estimation Systems for the U.S. federal Emergency Management Agency.
Yes, some idiot at FEMA gave a 14 year old a federal contract.
How did that go wrong?
What could go wrong?
Oh, wow.
I did a bunch of Commodore 64 and Apple II software back in the day.
I'm a lawyer by training, but decided not to pursue the law.
Wrote a spreadsheet for Next computers.
It was the thing that Steve Jobs did in between Apple and Apple.
Oh yeah, oh yeah.
And our product, you know, I had this three person company, Bootstrap funded and we beat Lotus out of the next market.
And Lotus was at the time the second largest software company in the world and they were the largest spreadsheet.
They were the spreadsheet.
Yeah, yeah.
1, 2, 3 Was the spreadsheet and we beat Lotus out of the next market.
Wow.
Did a bunch of other stuff.
Did a startup, got acquired, moved out to San Francisco, started my San Francisco adventure.
Kids came along.
I decided to be the stay at home dad.
Did a little bit of consulting.
One of my clients was this little company with six engineers and scaling problems and they were, they had this Ruby on Rails stack.
And so I helped Twitter transition from Ruby on Rails to Scala.
Also wrote a Scala web framework called Lyft and helped the Twitter folks, designed their back end.
Did a bunch of other stuff.
Was at Cisco for a bunch of years working on the firewall.
And most recently I've been looking at how to use the same math, the same Merkle trees, et cetera that Git uses, but on post build artifacts.
So we think about Git and Merkle Trees and what's the hash of this commitment?
I think of that as a thing that we do with source code.
And thesis for Spice Labs is why not do that for host build artifacts too?
So we have a map of 18 billion nodes of hash values and graphs and that sort of thing for most of open source.
And we have tools that Will build mathematical graphs of proprietary software, compare the two.
What open source are you using?
And the way that we're applying that is around discovering how cryptography is used within applications.
So sorry for the sales pitch, but.
No, not at all.
I mean you have at least.
Right.
So you've been around for like, I mean there's so much to unpack there even before we dive into.
But maybe before we go in, even there, like, let's go down memory lane.
Like working Twitter in the early days that must have been quite adventure.
Like that's.
How was that engagement?
Like, how does that look like?
What happened?
Trenches.
Spill the.
Spill the beans.
So imagine if your house is on fire.
Right?
Right.
And every time you put out a fire in one room, you have maybe 30 seconds before a fire pops up in another room.
How are you supposed to like clean your house when you've got fires in every room and no matter what you do, you can't put them out?
And that's what Twitter was back in 2008.
And yeah, this was before Amazon EC2 was a thing.
EC2 existed.
But if you wanted more than 20 machines, you had to provision them.
There was a lot of noisy neighbor problems on the virtualization platforms.
So Twitter quite literally was buying their own hardware.
So it was 90 days between the time they get a venture check and the time that they could install servers because they'd order the servers, they'd have to rack them.
This was all like, you know, caveman stuff.
I don't even remember.
I wasn't, I wasn't part of the racking and stacking team.
Right.
And you know, the site would go down and it would be an all hands thing.
Well, what we had to do was we had to mitigate the problems.
And I, part of what I did there was discover the root cause of the fail whale, which was a very interesting intersection between the C based Ruby runtime and memcached.
So because they had a limited number of boxes, they co.
They co. Resided the web servers and the caches on the same box.
Which makes sense.
Right?
Right.
Well, there was a bug in mri, the maps runtime in the Ruby runtime that occasionally the garbage collector would start asking for extra slabs of memory from the os.
And if you've got a cache on the same box, you then had a problem where the cache would say, oh yeah, I'm a cache, I'll give you.
You want some memory, I'll just give you the memory.
So that would increase the number of cache misses and that would put pressure on the back end database.
And all of these things were like, you know, at 97% capacity.
Because every time Twitter added new physical boxes and could scale up, they literally got as many users as would make the site marginally usable.
This is a problem every startup wants.
It's like every time we grow, people love us so much.
Right, Right.
Textbook.
Yeah, textbook.
Or textbook fantasy.
So we had this problem where the cache invalidation would then put pressure on the back end database because you'd have more cache misses.
And once you had more cache misses, everything would slow down and that would put more pressure on everything.
And then once you brought the box back up, you then have a cash stampede because you had more caching.
You know, we all, you know, we now, what, 17 years later understand the patterns.
Right.
But back then, a lot of these patterns were ones that we either discovered ourselves or there wasn't enough.
There weren't enough blogs out there to Google to find out what the heck was going on.
Yeah.
It's so interesting.
The tech stacks look so different back then.
I mean, not to say Rails, not a thing anymore.
It certainly is.
I mean, most stacks were running like PHP was a big thing back then.
A lot of the company, like Facebook, Like those were like kind of the big cabs back then.
Right.
Yeah.
And Java was a no go at Twitter because the engineers were either Ruby or Python people.
And just the ergonomics around Java and this was like pre Java 8 or around the Java 8 era.
So incredibly verbose language, no lambdas, none of the stuff that we now have in JavaScript, you know, and also no annotations.
So you couldn't basically just annotate a bunch of methods and have those turn into web routes.
So it was Java was a no go.
Right.
And Ruby was Ruby and Rails was an incredibly expressive and powerful environment when you've got six engineers.
Yeah.
And when you have six engineers that have a mind meld.
And they did, I mean, really, just freaking amazing engineers and amazing team cohesion.
And you know, it.
It got them to the right point.
Yeah, yeah.
Anyway, so, yeah, problems with the runtime and one of the ways that we solved there were two things that we did to solve the problem or to stem the fire.
First thing that we did is we put a cron job in that would kill the Ruby processes, the rails processes every 15 minutes in a round robin fashion.
Yeah.
But, you know, it was the cost of cold starting a Rails instance versus losing your cache.
Right, right.
The second thing is there was one endpoint, the public Timeline endpoint that received about 20% of the traffic.
And the thing that I did before south by Southwest 2008 was I rewrote that using Lyft and were able to basically reduce from, I think it was at the time, 15 boxes that were serving the public timeline to one.
Oh, wow.
Yeah.
And so that first of all gave us more box physical boxes to serve the other endpoints.
And the second thing is a public timeline was not causing the pressure on the overall system because being able to write in, you know.
Right.
In a.
For a runtime that was faster and have multiple threads and be able to share data across the threads without having to go out to the cache, etcetera, Sped things up significantly.
So that's moved us from having the fire in every room every day to maybe having one fire a week, which gave us the ability to then sit down and start doing a rational design around the migration.
And you know, it's.
Sometimes you have to do the triage, you know, to stem the bleeding.
Yeah, you can figure out how to do the surgery.
And once again, the team back then was just such a freaking amazing team.
And yeah, we moved from firefighting mode to a mode where we could actually sit down and think about the problems.
And the team put together a really nice message oriented design.
And the rest is kind of history.
And you know, the way I put it is the design the team came up with that started the evolution of the kernel of the design.
Yeah.
Survived Elon Musk and his, oh, let's just take a chainsaw this stuff.
Right.
The fact that the system is still so amazingly resilient.
Right, right.
Is a testament to the team that put the original design together.
And then the way that Twitter evolved, the engineering team and then their public trust team and the security team to like really care about the structure of what Twitter was building.
And you know, I think to a great degree, the doing things ethically and right kneecapped Twitter from a revenue standpoint.
You know, Mark Zuckerberg famously called Twitter, quote, a bunch of clowns that drove a clown car into a gold mine.
And I think of it exactly the opposite.
I think it was a bunch of people who really cared about doing the right thing and creating a public forum.
And whether it was investing in the technology and the people that built the technology, or investing early in security and trust, those things were done correctly and ethically.
Yeah.
You know, Twitter didn't become a 200 billion dollar company or a trillion dollar company, but it did become a company that fundamentally altered the way that humans had conversations.
Yeah, yeah.
I mean now, I mean, obviously with mustard and everything, like distributed models and all those things have happened since.
But like, it is true, like they.
They definitely had a very big.
And they did some really cool stuff.
I remember back in the day, the Wilson using protocol for like deploying software updates internally, something along those lines.
That was after my time.
But yeah, I mean, the thing is that when you have a stable foundation, you can then explore and when you have the social safety or the psychological safety on the engineering team to be able to try things, then you try things and sometimes they work and once again push boundaries.
When you have a human structure that allows you to push boundaries.
No, no, it's pretty impressive.
I mean.
Yeah.
To be able to run the same stack this many years later.
I mean, that's very impressive indeed.
Yes.
Super cool.
I can't turn now to the main topic of today, what we're going to talk about, which is post quantum crypto.
We were chatting back in Moki Gras a few weeks ago in London and we talked about that, but eventually our conversations shifted over to post quantum.
And it was a rather timely conversation because the same week I believe Google published their updated paper on breaking quantum breaking encryption using quantum.
Maybe for those audience who are not.
Who even know what this means, because this sounds like a word salad to a lot of people, even in engineering.
Like, you need to be kind of like it's a bit of a.
Let's take a step back.
What does it mean?
What does post quantum crypto mean?
What are the implications?
Why should people care?
So let me start with the implications and why people should care.
We have, you know, over the last 20, 25 years, built this beautiful thing that has connected our entire species, or at least 70% of our species together.
Yeah, we're having a call or a conversation between the United States and London or, I'm sorry, Bristol.
Yeah, yeah, close enough.
We're having this trans.
Transatlantic conversation.
Yeah.
Casually drinking coffee, talking about stuff.
I mean, I got a cat in my lap.
How, you know, back in the day, who.
You know, if you had a transatlantic call, people would get dressed up in suits even though they couldn't see each other.
Right, right.
It was important.
It cost money.
And now like, hey, yeah.
How many people WhatsApp each other around the world every day, Whether it's text or voice or whatever.
We're now a connected species.
And getting back to the Twitter thing, part of what Twitter did was create this global conversation we have through the history of Building things on the Internet with one exception, always put adoption way before security.
And the one exception was tls, which sits on top of two different encryption protocols and a handshake protocol.
The two encryption protocols are their RSA or elliptic curve.
And the handshake is Diffie Hellman.
I'm sorry, Diffie Hellman.
We trust that.
We trust what, you know, when we use our mobile to talk to our bank, we trust that we can do that without adversaries getting in the way.
You don't think about North Korean hackers draining your bank account just because you use your mobile to check your balance.
That's because of encryption.
That is a level of trust, inherent level of trust that we have in our communications and in our interactions with other systems.
And it has worked very well.
So what is at stake here is the trust that we all implicitly have in the communications and also in the documents.
And the documents are an important part of this.
So if you use DocuSign, you sign something, you know, using your.
And get a PDF.
That PDF is digitally signed.
And that means that your signature and the information about your signature can't be repudiated.
Your signature can't be copied onto a document that says something else that is also digitally signed.
The U.S. department of justice uses digital signatures for chain of custody in their criminal cases.
Banks, when they do reconciliation at night, you know, HSBC might have 200,000 transactions with bank of America every day, but the net amount of money that's moved between the two is a lot smaller than the NET of the 200,000 or the gross addition of the 200,000 transactions.
So every night or periodically they do reconciliation, saying, hey, you know, there's, you know, $2 million that I have a net of $2 million that one owes the other.
That stuff is digitally signed.
So there's a record of who said what, who transferred what to whom, and when Bitcoin is built.
And, you know, the cryptocurrencies are quite literally built on cryptography.
And we trust those transactions because of proof of work, proof of stake, you know, the various different cryptographic proofs.
And we protect our, the private key for our wallets.
Some people do it at gunpoint.
You know, there have been kidnappings where people have been kidnapped to get the private, or to get the password of private key to their wallets.
Yeah, these things are all huge.
Now.
What happens when that trust is eroded?
It is a societal and seismic impact.
And because these trust mechanisms are built into everything that we do, they're almost invisible to us.
It's very much like, you know, the electricity that comes to your house or the plumbing, the water that comes in, the sewage that goes out.
We know that it happens, but we take it so much for granted.
It is invisible to us.
And, you know, we don't think about a world without that.
Yeah.
So that's what's at stake.
It's that trust.
It's the trust that we've built up with technology over 20 plus years now.
You want me to go into the.
Yeah, I think you're painting a very good picture here of why this actually matters, because I think it's easy to get too academic about these things and not see the real world implications of why it matters.
So the underlying how is the problem.
The way that both RSA encryption and elliptic curve encryption work is you have two very large prime numbers.
You multiply them together and you give them the product.
To me, the two prime numbers make up your private key and the product of those two prime numbers.
And look, you go through some machinations, but this is the fundamental math behind it.
The product of those two prime numbers is something that can be used to encrypt data that can only be decrypted if you know what the two prime numbers are.
Right, right.
The computational cost of doing what's called prime factorization of numbers of that size is computationally difficult.
So using our existing computers, it would take until the heat death of the universe, even with like GPUs and everything else.
Right, right, right.
To discover the two prime numbers that make up the public key.
From the public key.
Right.
Because you basically have this brute force and guess over and over and over again until you've derived the right conclusion.
Quantum computers, because.
So let me talk a little bit about quantum mechanics because it is an absolutely irrational branch of physics that.
It's irrational from our standpoint, but it is the basis of our entire universe, our entire existence, which is.
I'll use the Schrodinger's cat metaphor.
Schrodinger's cat is a thought exercise where you have a cat in a box.
The box has a vial of poison in it.
And the vial of poison can be cracked or not cracked, depending on whether a single atom has a particular attribute, a particular spin.
Spin is just a mathematical term.
It's, you know, there's colors and spins and all kinds of crazy things that the physicists, who apparently took a lot of acid thought up.
Anyway.
Sorry, my dad was a physicist.
He did not touch acid.
But that's entirely but you don't know whether the cat is both alive and dead at the same time until it's observed.
Until you observe what that state.
The state of that atom is.
The state of the atom is in both positions.
It's called superposition.
Right, Right.
Back in the 90s, there was this guy named Shore who figured out how to use quantum superpositions to create an algorithm that could do prime factorization.
So something that would take our classic computers hundreds of billions of years to solve using Shor's algorithm will take milliseconds, or depending on the quantum computer, maybe a few seconds or a few minutes.
But it's quite a scale time, quite the delta.
And the.
The trick is you don't observe the intermediate representations until the algorithm is finished.
And when you observe the output, that's when the superpositions collapse into the right answer.
Now, I'm simplifying the hell out of it.
Yeah, I. I don't quite understand that.
But, yes, I think I can roughly.
Get the sense of it just nobody, or I shouldn't say nobody.
The number of people who actually understand quantum mechanics is very limited because it is incredibly counterintuitive that something doesn't happen until a human observes it.
Right?
Right.
So all of a sudden, we can do this prime factorization.
And the question is, how many quantum bits or qubits do you need to be able to do prime factorization of large numbers?
And it turns out there's a formula for this, and you need some multiple of the number of bits.
So if you have RSA 4096, it's 4096 bits.
So how many qubits do you need?
I think it's about 12 or 15,000.
Elliptic curve uses 256 bits.
So how many qubits do you need?
I think it's like 1200, 1500 cubits.
And there is a huge engineering problem around doing what's called coherence across the number of qubits, across the number of atoms or other quantum material to do the calculation.
So there is just a ton of engineering.
And, you know, there are a couple of different ways of doing this.
One is called, I think, free ion.
The other one is superconductor.
My son's a physics major.
He explained it to me once over dinner, and I promptly forgot it.
But there was a paper out of China, I don't know, a year or two back, that where they broke 50 bit.
They actually demonstrated with one of their quantum computers, they were able to break 50 bit RSI.
So the.
When Will classic encryption be broken?
Question has always been the same.
Answer is when are we going to have fusion power?
Which is it's always 10 years away.
Right, right, right.
Except we're actually solving a lot of the engineering problems and Google came out and said 2029 is when elliptic curve will be breakable with quantum computers and that's going to allow forging of Bitcoin transactions.
That is so terrifying that it's hard to even comprehend because the ramifications of that are so massive.
Because historically it's just been equation.
Like when people talk about breaking encryption previously, Like 2024 used 2048 and used bump, you get slower operations.
It doesn't really matter at the end of the day.
Right.
But now it's just a question of like it doesn't matter anymore.
Yeah.
And so there are a series of cryptography algorithms that are called lattice based cryptography.
They use more bits and they require more computation.
And the sub parts of the computation are not built into hardware.
So most of our processors, you know, most modern processors have for example, SHA2 that a lot of the pieces of doing SHA2 hashing, you know, SHA256 built into the hardware.
Right, right.
So it's not a software.
The software loops are much faster.
Right.
A lot of encryption also has hardware support.
The lattice based encryption does not.
And the key lengths are larger and the computation required is heftier.
So yeah, the new algorithms were not necessarily thought of as we want these now for a bunch of reasons.
I mean, you know, if you've got a fast motorcycle, are you going to trade that for a tractor?
Yeah, yeah, exactly.
Because it's so such a core building block in anything we do today.
Right.
We take this for granted fully, that it's just going to be encrypted.
We know the latency of doing encryptions, it doesn't really matter.
Right.
Normally, like it doesn't matter for both companies.
Right, yeah.
And so the other thing that you alluded to in the past a few minutes ago was the fact that we do discover flaws in the algorithms.
So we have had relatively stable algorithms and changed bit size for the public key encryption for RSA analytic curve for we move from DES to triple DES to AES for symmetric key encryption, you know, but that has evolved and AES seems to be.
Nobody's broken it yet.
Nobody's found weaknesses in it yet to.
Our knowledge, which I think is an important caveat.
Well, so the Google paper that came out is the stuff that we're Seeing above the waterline to.
That's what I was like.
We know he's probably five years behind.
Yes.
And the question is, what do governments with substantial budgets and substantial ability to keep things secret, what do they have?
And you know, once again, going back to my conversation with my son, he was talking about how hard would it be to set up a big enough quantum computer to solve these problems in a way that is, that can be hidden budgetarily.
So, you know, if you have a 50 billion dollar quantum computer and it is, you know, requires a lot of cooling and a whole bunch of other stuff, hiding that is hard.
So the constraint becomes hiding in the budget, not the fiscal constraint.
Building it.
Well, it's hiding it in the budget.
Building it in a way that it's not going to be seen by spy satellites.
So if you have a lot of like detailed data, sensors.
Right, right.
Yeah.
But then you say, okay, why is, yeah, why is.
I'll, I'll pick on Canada because the folks from Talos Group at Cisco that I used to work with always, you know, called Canada the adversary, because Canada is never the adversary.
Well, so, you know, if Canada all of a sudden started doing a lot of excavation of mountains, so they were hiding something, everybody be like, okay, what are they hiding?
Yeah, I'll be like, what World War II era building something new.
Right.
Yeah, well, that's, I think that is to a great degree a Western mentality.
So, yes, in Europe, North America and Russia, there is a lot of stuff to repurpose.
What about China?
True.
And you know, how do you trunk in enough power to power these things?
So one of Daniel's suppositions is that quantum computers using the free ions are much lower cost and much lower power than the superconducting ones.
Interesting.
But the challenge with the free ion quantum computers, and you know, he said, look, you could probably build it in university, the basement of a university lab, probably for under $100 million.
And you know, $100 million is a lot of money.
But you.
Not for these things.
Right, right.
Not for these things.
And also think of thinking about, you know, budgets of large Western countries.
I mean, Germany just passed a bill where they're going to spend 500 million euros a year on carbon capture.
Yeah, okay, so they're doing carbon capture at, you know, big scale.
Could they hide 50 million euros of that to do some quantum stuff?
Yeah, sure.
Yeah.
So the techno, the quantum technology being used is part of the equation.
How you hide it is part of the equation and whether you have it as part of the equation and this.
Well, let's just talk.
Let's circle back to Bletchley Park.
Yeah, go ahead with your question.
No, no, I was gonna say, because one of the things.
Purists to my knowledge consider that there are no quantum computers.
Yeah, right.
There are quasi quantum computers.
Right.
That is my understanding of it, how much that is true.
What is a real quantum computer versus non real quantum computer?
Look, my son's an undergrad at Boston University, which is not mit, it's not Harvard, it's not Stanford, and he built, I think a 4 or 6 bit qubit quantum computer as part of one of his lab exercises.
I just remember.
Yeah, Because I remember back when a friend of mine was over at Stanford Research doing something there, and I remember that some new quantum computer, AI computer, tried to donate one of their quantum computers to Stanford cst and they're like, no, we don't want it.
It's not a real quantum computer.
But that's quite a few years ago.
Yeah, I mean, it is.
You know, think of it this way.
The quantum computers that are necessary to break encryption are similar to the amount of computing that we have in our iPhones or our Android phones.
This is not a direct comparison.
It is comparison to going out to the store and buying two or three hundred NAND gates and wiring them together into a very simple computer.
So, yes, we can buy a couple hundred NAND gates, wire them together into a simple computer that is, I don't know, million times slower than our iPhone, 100 million times slower.
I don't know, some vast number of times slower.
Does that mean that.
Yeah, it means that building a computer out of NAND gates is a possibility.
And it becomes an engineering thing to say, how many transistors or how many NAND gates can you wire together and manage at the same time?
Which is the engineering challenge, not the core.
Can you build a computer challenge?
Okay, okay, fair enough.
Yeah.
Okay, okay, fair enough.
Yeah.
So anyway, The issue, the Bletchley park issue is During World War II, we could break German encryption.
When I say we, I mean the Allies.
And I figure, you know, you're in one Allied country, I'm in another.
So we.
Yes,.
And we kept that secret.
And there are some documented cases, you know, if you go tour of Bletchley park, there's some documented cases where they knew attacks were going to take place and they did not warn the Allied commanders that the attacks were going to take place because it would have revealed too much about our ability to break encryption.
So the.
How powerful are things?
What.
What's below the waterline is quite literally a state secret.
Because if we.
If the US could break encryption and we could listen in on an adversary's conversations, we don't really want the adversaries knowing that we can listen in on their conversations.
Yeah, yeah.
I mean, I guess.
I guess this kind of takes us to the Snowden papers, right, what were revealed back in those data dumps.
I forgot the exact phrase that was used, but it's like capturing a harvest later, I think it's called.
Right, yeah.
And the concept being that, yeah, we cannot decrypt this data today, but there will come a point in the future where we can.
So let's just capture everything.
And, yeah, you'll see occasional BGP routes that send a substantial part of U. S. Internet traffic through China.
I wonder why that's happening.
Right?
I don't.
I'm being sarcastic.
The.
The harvest now, decrypt later problem is a problem, and I agree with that.
But I actually think the forgery problem is a bigger one.
Yeah.
Because the breaking of trust and the draining of bitcoin wallets and the throwing into doubt the trust pillars that we have are the things that erode our social fabric.
And a lot of western society, a lot of democratic societies, are built on trust.
And when you erode that trust, when normal people stop believing in the institutions or have reasons to doubt the institutions, that leads to an erosion of power.
Because our power, or soft power, comes from cohesion.
And breaking and breaching the trust damages that cohesion.
Yeah.
Yeah.
I mean, this really is like a massive extension of what we've seen in many countries where, like, there is little trust in public news sources, for instance, or public not coming out of the government.
Right.
And this is kind of an extension of that.
You can see this firsthand in.
In countries, I mean, where they don't trust any news sources.
So what happens, that vacuum is then filled by Facebook and like, these WhatsApp groups.
Like, you've seen that one, Pakistan.
You see that lot.
Like, you see a lot in.
You see this a lot.
Right.
But this is like, this is not like fake news.
This is like the fabric of society.
It's like so many levels deeper to road.
Right.
Yeah.
So we have, what, three years, maybe four years to fix the problem.
That are still running mainframes.
So just put it back to a fast.
Right.
Yeah.
And you know that.
That talking about mainframes is actually interesting.
Because a lot of people have been analogizing the problem that we have now to the Y2K problem.
Yeah, yeah,.
Right.
And so, but mainframes, I think were a critical part of being able to solve the Y2K problem.
Because at the time the chief information officer who had to certify that all of the systems would work on January 1, 2000, could go to the CFO of a company and say, give me a list of all of our mainframe leases.
That would give them a list, effectively the starting point for saying, who's got software on these?
What software are we running?
And that was a bounded list.
Yeah,.
Big bank, maybe two, 300 mainframes.
I mean, you know, these things were millions of dollars a year in lease fees.
Yeah, yeah.
Now we're pushing new versions of software continuously.
We have millions and millions of servers at Amazon or AWS and Google Cloud and name your cloud provider.
How do we even inventory where this stuff where we're using cryptography, we can look at the TLS handshakes for network traffic and make sure that they're TLS 1.3, make sure that the right algorithms are being offered and accepted.
And Cisco and Palo Alto Networks and the other firewall vendors all have various different firewall rules and other DPI and stuff.
Yeah, yeah.
So that stuff is a bounded problem.
So the harvest now decrypt later is a bounded problem because it's mostly public Internet traffic, it's mostly inspectable through firewalls and it's also proxyable.
So if you basically have some old, you know, 32 bit Solaris system that can't be upgraded to use the lattice based algorithms, you can put a proxy in front of it to do the translation, you know, to do the TLS handshaking and turn that from TLS 1:1 to TLS 13.
And so those are solvable problems.
But the where are we digitally signing things?
Where are we encrypting at rest using public keys that can be anywhere in any of our software stacks.
Yeah, that's.
I mean, just a slight tangent, but I anecdotally heard this from a bank in the uk.
It's related to mainframes.
It's just a funny side note, but one of those big acquisitions going around and merging between the different banks in the uk.
I forgot the exact names, but I heard from somebody working there.
And basically after acquisition, the one company, one bank swallowed another and they were consolidated data centers into one big data center.
And as usual happens.
Right.
But there was one mainframe left nobody owned and nobody Knew what it did.
Right, right.
It's just been ticking along there since the 70s.
Nobody's been touching it since the 70s.
And well, the final day comes and like, well, we gotta pull the plug on this thing eventually.
Like you gotta see what happens because nobody did.
And they pulled it.
And wire transfer stopped working.
This is just a piece of machinery that's been running probably some copilot app.
Copil app.
Right.
Since the seventies.
Bug free, more or less since the seventies.
Right, right.
But imagine doing an audit on that where you probably have like, you don't know who wrote it, you don't know how it's written, you don't have the source code.
Maybe have the source code.
But doing to your point, that could potentially or possibly be doing some kind of like crypto signing off those transactions.
Right.
How do you even start.
Like this is such a large magnitude problem.
Right?
Yeah.
And at an organizational level and you know, we're starting to move from okay, what does one team have to do to how do you manage an.
At fleet scale.
And the people who are responsible for fixing this problem and for certifying that they are, they have the right algorithms across their enterprise is typically the Chief Information Officer or the Chief Information Security officer.
Yeah, yeah.
The tools for discovery, with the exception of Spice Labs, all require source code access.
Yeah, yeah.
And I mean that's a. Yeah, that's a really good point.
Right.
Which misaligns the authority, the responsibility and the authority, because the CISO or the cio, they don't have the authority to go to every engineering team and say install tool X or install tool Y and being able to narrow down from.
Yeah, okay, we know that we do continuous delivery from Artifactory or from Docker Hub or from GitHub Container Registry or wherever.
Most companies have one or two choke points where substantially all their artifacts go through.
Being able to go and look at those first to say, okay, we're going to inspect what's here with an automated tool.
Bulk download, bulk inventory, bulk discovery.
Great.
We might have 20,000 microservices at our bank, but there are only 600 of them that are doing digital signing.
We've identified the 600 that are doing digital signing.
That's a much easier and healthier conversation between the security team or the CIOs team and the engineering team.
Look, here are 600 modules that we need you to go look at and you know, can we meet in two months and have the initial report on what your remediation plan is for these 600 modules?
But speaking about remediation, if you have a modern Python, I mean in the insert blank line, it doesn't really matter.
Right.
Like there are some open SL library probably that's doing crypto.
Right.
That's not a problem.
Like as long as you know what you're solving, as long as you know where the problem is, solving that problem relatively is easy.
Right, right.
Because then like we tweak some function, now you need some algorithm problem solved.
Right.
Once you've done the discovery part, not saying it's easy, but it's relatively that.
Right.
How the hell do you deal with.
2024?
That's like building block of that language because it doesn't have any more modern version.
That may, you know, so there are different levels of remediation that we have to think about.
You've identified, you know, kind of the easy case and the hard case.
But let's look at the easy case for a minute.
Right, right.
Because the easy case it because we have always trusted our algorithms and because we don't change them very frequently, the algorithms are baked into the code.
Yeah, yeah.
But the lattice based algorithms are relatively new and relatively untested.
And just as we saw a bunch of the symmetric key algorithms were weakened and broken back, you know, over the course of the late 90s through the 2000s, I expect that the lattice based algorithms there will be weaknesses found and we will have to update the algorithms.
So, so there are two different things at play when we do the updating of applications that are easy to update.
The first one is we identify them, but we use the jargon in the industry is crypto agility.
So rather than defining the cryptography algorithm and the number of bits and all of that sort of stuff in the code, you define it in a configuration file.
And when I say configuration management system, an abstraction.
But it's an abstraction where you can say, okay, we can change the cryptography algorithm simply by ensuring that the library that's being used supports it.
And we're now good enough with patch management that we can update our libraries pretty easily and pretty regularly.
And we know how to do that.
Nobody likes doing it's not fun.
But we know how to do it.
It's, you know, kind of like any other chore.
You know, I really don't like cleaning out the gutters in my house, but you know, twice a year I go out there and pull the leaves out of the gutter so the things don't come on.
Right, right.
But insurance, there's crypto agility is critical because we know that in five years or 10 years, we're going to have to update the number of bits that are being used, maybe change the algorithms, etc.
So ensuring that the algorithms are not baked into source code, but the choice of algorithms is done from a configuration management system.
That's crypto agility and that's part of the equation.
Now the other part of the equation was the one that you referred to, which is the remediation hard cases.
You have a Fortran code base or I'll actually pick on Java 5 here because that's.
Yeah, that's more likely you've got some weirdo free code that you can't upgrade from Java 5 JVM.
You're using some sun, blah, blah, class that you know you shouldn't have been using.
But here we are.
Here we are.
How do you go in and spend the time and the effort to effectively rewrite the app or port the app?
And you know, look, everybody's going to say, we'll do it with AI.
And I'm going to say, if it's hard for a human to do.
Yeah.
A lot of those code bases don't have tests.
I was just gonna say, you have a test case.
Yeah, I mean, look, AI is great when it's goal seeking.
Here's the test, here's a blank canvas.
Make the test pass.
Okay, I can do that.
Right, right.
Add some more tests, like performance tests and all kinds of like, hey, how can I break this stuff?
Oh, right, okay.
The tests break AI, goal, seek and you know, write the code and do it.
When you don't have the tests, it's problematic.
I mean, we saw this when Doge came in and said, we're going to rewrite the Social Security Administration's COBOL in three months using AI.
That was.
Yeah.
So, yes, dealing with the legacy code bases and dealing with the things that people know inherently but are not well documented.
You know, it's tribal knowledge that becomes a real problem.
And as you said, I think earlier in the conversation, a lot of the people who knew about this stuff have retired.
Yeah, yeah.
Or dead retired or permanently retired.
Yes.
So that is a hard problem case.
But being able to identify those things as early as possible gives businesses two different wins.
The first win is, okay, can we isolate this thing?
Is it cheaper and easier to put a wrapper around it?
You know, I talked about the wrappers that are put around systems that can't be upgraded to TLS 1.3.
You put a Proxy in front of it and the proxy does the work.
Is there a way of wrapping the system in a proxy?
Right, right.
The second way is, okay, we're going to scope the rewrite.
You know, we've been putting this off and yeah, think about the way that most corporate VPs live their lives.
They sit in their chair for 18 to 36 months and then it's somebody else's problem.
Yeah, yeah.
So you know, rewriting that.
Yeah, yeah.
Or the Fortran app or the COBOL app on that mainframe that did wire transfers.
That was always somebody else's problem.
Right, right.
And all of a sudden somebody's got to face the fact that it's their problem and they have to budget for it.
But it's better to know that it's your problem now rather than discovering that it's your problem six months before.
Yeah, before what's below the waterline comes above the waterline.
Yeah, yeah.
I mean, I mean so much sometimes.
I mean because I mean before our last conversation, my entire headspace was around transit, right.
Like TLS and all that stuff.
Right.
And that's I think where most people's headspace were at.
Not around the document signature stuff.
That is actually to your point, very much part of the blueprint for western societies.
And I mean even beyond Western, to be fair.
Right.
It's presumably like all the modern civilization, right?
Everything we do.
Right?
Yeah, It's a lot to take in and like not that long time ago, Google's paper, it's not that far away.
Right.
And I wanted to raise another thing which is since the last guy I started doing internal audit of like what are we doing?
Right, what are we doing?
Like I'm curious about obviously set up lattice, problem solved.
Then I run into a problem which is we use TPM solid screen for doing cryptography operations.
There is no single.
I mean TKMs are fantastic.
They're great for increasing security posture.
You know that like if it's in the TPM you can't read it back with an asterisk.
But like you can unless you like have nation state attack against you.
It's safe, right?
None, none other tpms support anything that's post quantum safe.
So the harder rule of trust and this goes beyond just like those things, right?
That's what mostly is used for, like signing trust traffic, but this goes far beyond that.
It's like every CA out there is using like the tech series, security series, they are using HSM for backing their backing the root keys Right.
That they sign everything with, well, how many HSM are cross quantum safe?
Probably zero.
My guess is Amazon either has it or will have it.
They.
AWS is taking this stuff very, very seriously.
They have.
My understanding is they have a 2028 deadline for making sure that the AWS infrastructure is quantum safe.
I haven't.
I haven't found the.
A public citation for that, but the conversations that I've had have.
All.
All the conversations that I've had have said, yeah, AWS has internal programs and their deadline is 2028.
Which, you know, given that another one of our roots of trust is aws, you know, AWS east goes down and the doorbell in Bristol.
Yeah, yeah, your doorbell in Bristol stopped ringing.
Right, right.
You know, it's true.
But this is like software versus hardware.
Hardware is always so much more difficult because the lag there is just so much slower.
And it's just.
I mean, I mean, I'm not sure what you've seen, if there is any light at a tone there, like, what are we doing?
Like, we can't just give up hard Revolution because that's like, so core to what we need to secure our infrastructure.
I mean, beyond Amazon.
But you've just highlighted another forgery problem.
So if our hardware roots of trust are all classic pki, RSA or elliptic curve, forging an application, discovering what Microsoft's private key is, or discovering what Apple's private key is.
Holy.
Yeah.
Now you issue like a certificate for any single domain on planet Earth.
Yes.
And you're browsing with the.
No difference.
Well, you know, can you get Veris Signs private key?
Yes.
So, I mean.
Yeah, so when I say the trust infrastructure of, you know, I. I said Western civilization.
You said civilization as a whole.
I. I accept your correction.
All of this stuff is based on these prime numbers.
And these prime numbers are going to be factorable.
Yeah.
I mean, it just made me realize that this is completely unrelated, but actually became very related.
I was doing a CA company a long time ago trying to do security for IoT devices.
Went nowhere because people didn't want to pay for it.
But it doesn't matter.
The point was that I went down, deep down the rabbit hole of PKIs and CA infrastructure.
And that was around the time that transparency locks became a big thing.
Cloudflare made a big push for this.
Right.
And now they basically publish and let's encrypt the same thing.
Right.
Like you can actually find the audit trail for every certificate they issue and so forth.
Well, maybe that is the mitigation strategy for at least for certificates.
If it's not in the transparency log, well then it's probably fake.
So that is actually the one of the mitigations that I've been talking to some of our prospects about, which is if you've got, you know, let's say 7 million documents that you signed with Elliptic Curve or RSA, you can't go back and resign them.
But what you can do is you can hash them and then you can sign the hashes, not one by one, but you basically say, here's a corpus of hashes.
Let's get back to Merkle trees.
Here's the Merkle tree of this body of documents.
We've rehashed the document or just quite frankly put them in git and then sign the git commit digitally sign the git commit with lattice based signatures rather than RSA signatures.
And then you can say, okay, we have.
Even though the signature is not on the document, if the document's not in the repository, it was not a legitimately signed document.
I mean, yeah, that's an interesting one which brings up another category which like you're safe signing key can also would now be faked because it's based on EC or rsa.
Right.
But what you need to do is you need the new signing key based on the new lattice based algorithms.
Right, Right.
But none of the.
I mean GitHub doesn't support that for signing, for instance, right now, to my knowledge.
So you don't do it at GitHub, you basically.
Yeah, I understand.
Like the maturity is not there.
Right.
Like I'm sure you can do it, but it like other tools will do it out of the box.
SSH probably doesn't even support this.
Right.
As of yesterday, I think it is.
SSH will start issuing warnings if you're using classic algorithms for connecting.
But that's basically everybody.
Yes.
Even if you like ecp.
Right.
I mean, yeah, but what it's doing is it's going to put in Everybody who uses SSH's face.
The fact that.
Tick tock, baby.
Yeah, wow, That's a different story.
But wow, there's so much to unpack.
I mean I'm still like even still after we spoke what, three weeks ago?
And I'd still be like, holy shit.
I still haven't gotten over the shock of that conversation really.
It's so spans everything.
And if you can fake the certificate.
Right.
You can fake the serial number in that certificate too, presumably.
Right.
So then you can just say, well, this is the serial number in this certificate from the certificate chain.
Transparency chain.
Well if I know all the data I just fake that too but then actually that is void.
So at some point this gets back into distributed trust.
Yeah, yeah.
So it used to be that folks would publish public information in newspapers and not just one newspaper, but many newspapers.
Because the ability to destroy, you know, go out and destroy or call into question, you know, the New York Times and the Financial Times and the Washington Post becomes difficult.
The number of physical copies.
You know back in the day you'd put the physical copies in libraries and they'd be on microfiche.
So a lot of these problems I believe can be solved also just with replication.
So a certificate, a transparency log helps a lot because it's not just a log on a server.
It's a log on a server that's probably been copied to many different servers.
Yeah, yeah, that's.
Yeah.
But then it gets back into you know it gets back into the.
And how do we manage at scale the potentials forgeries and you know, if you're forging an Apple, Microsoft or Apple signature to get something into the root of trust for device.
Hey this is you know an OS update signed by Apple.
Right, right.
Your phone ain't going to be like searching certificate transparency logs.
No, no, that's kind of my point.
Right.
Because like we've been picking back on this safety net for so long because like.
Yeah, yeah.
I mean you assume that the transport is safe so like you are not even gonna think that is attack unless you're like.
Because you can't really man middle of the stuff.
Like that has not been a thing like it's like has not been like an impossible attack vector.
Has not.
So much here the last thing I wanted to come about.
We are coming up on time here and I, I try to keep like less than an hour 20 but we are always.
Lastly I want to do talk about like what's under the water and what's above the water.
Classic classic crypto rsi.
And we there have been about backdoors in the various ARCs RSA in particular.
You've been living this world for a while in the crypto world.
What's your thinking?
It doesn't really matter anymore.
Looking back what is the plausibility or probability of RSA being backed up?
Because that rumor has circled for a long time.
I don't think it's true.
And the reason that I don't think it's true is at some point the NSA and NIST woke up to the fact that they're not the only ones that have the ability to do the research and the ability to discover the weaknesses.
Right, right.
You know, Russia has a huge set of awesomely trained mathematicians.
I don't know about China, but given the amount of publication and the amount of science that's going on in China, it's fair to assume.
And, you know, this is, I think, also why, especially after the Snowden papers, the NSA stopped hoarding zero days because, yeah, what they got was something that others were similarly capable of developing.
So my sense is RSA is safe.
I don't know enough of the math to be able to say that for a true fact.
Sure, sure.
Very, very few people are.
Yeah, I, I actually back in the 90s, met the woman who led the charge for elliptic curve.
Oh, wow.
Yeah.
IBM.
My company was doing a partnership with IBM and were all at Comdex and they were trotting her out because she was like the world's leading cryptography.
You know, here's a new, fewer bits, more safe way of doing photography.
You know our.
For elliptic curve.
What is it?
25, 519.
Seen what?
Whatever the curve is, was that curve chosen because there are known weaknesses?
I don't think so.
I, I think, you know, we collectively learned the lesson that if we put a weakness in, the weakness can be used against us, just as we can use the weakness against others.
Yeah, yeah, yeah.
And also, like harvest zero days.
Right.
Like, as you've seen with like Mythos and well, just copy.
Right.
Like, why would you harvest these?
They will be surfacing quite quickly.
Like there are more availability that we could patch anyways.
Yeah.
And you know, it's interesting with Mythos because even without Mythos, I was able to before my cup of coffee or while I was drinking my first cup of coffee in the morning, enter some prompts into Gemini that listed a series of very well known packages in the Java ecosystem that have remote code execution vulnerabilities.
One that was publicly patched and I got the acknowledgment for it was C3PO, which is a Java JDBC pooling library.
And yeah, if Mythos is trained specifically to look for vulnerabilities rather than these simple prompts that I entered, it concerns me deeply because figuring out where the vulnerabilities are is not hard.
Yeah, yeah.
And I mean, what I hear from people who are in positions high up in companies that have serious threat models, have serious attacks against them, they don't even look at The CV databases because by the time the CVE it's already done already been exploited in the wild.
So like CVE is a lagging indicator like DDR caps worse.
Right.
The reality is that there are so many more exploits in the wild that we can't even keep track of this thing.
So like it's changed the entire supply chain dynamics.
Like harvesting nowadays maybe not as useful anymore.
It was back in 10 years ago.
Yeah.
The other thing is that there's so much noise now that's been introduced by the kind of low end bug bounty people.
Yeah.
And that noise is in my opinion of similar magnitude for danger as the vulnerabilities themselves.
Because if you know, if you have a lot of either false positives, you know, you listen to Daniel who did curl.
He'll talk about like all the slop that he gets constantly and he's got filter through that.
Yeah, yeah.
Sometimes it's false positive, sometimes it's.
Who cares.
Like the vulnerability in postgres that required you having root access on the machine.
Right, Right.
Yeah.
You can't do anything without.
Right.
Thank you.
Yesterday Kate from Red McCully's piece which Daniel, I was in there as well.
We have a vulnerability program at Screenling and very much your point.
Banding vulnerability program is very expensive today because the barrier to entry is so low.
I mean there are so many open source tools out there.
You just point by the website blah.
Now the problem is you as a receiver of that you can't just dismiss it.
You need to actually investigate it.
Because what if you might look like a skip kiddie and they might not even that there are reproduction but doesn't mean wrong.
You might miss something.
So it's the asymmetry.
The effort to Review A report vs reporting a report is a massive problem.
I don't think anybody has a solution for that problem.
Yeah.
And you're right.
And that is actually weakening our security posture.
Yeah, yeah.
Because you don't know what's going to resources.
Yeah.
And you know, so just rubbing some AI on it is not going to solve the problem.
No.
We have to write some custom tooling just to do some rough triaging of.
All the reports we're receiving.
We're relatively small company.
Right.
We have like.
I think the number I gave Kate I think is like in the 300 plus reports we've had in like six months.
Right, right.
Wow.
And that's.
And that's okay.
Okay.
The vast majority of them are garbage.
Right.
From Kitty.
That doesn't even know how to run their own tools.
Right.
But they just like download something on GitHub.
Right.
Hoping for like a payday.
Right, Right.
But us as a receiver, we still need to treat every single one as a potential like P9.
Right.
Because.
Because.
Or other scary user.
But it's like, it could be like what if?
And you can't just write that off.
And that's why it's so difficult.
Right.
Like.
Yeah.
So yeah.
And managing things, you know, for a small company is one thing, because you can talk to all of your co workers and you can have a collective understanding of what's prioritizations are.
Yeah, yeah.
Imagine big companies where political capital.
You don't.
Do you want to use your political capital or not in a particular situation?
And part of the calculus is not simply doing the right thing, but it's what is my, you know, what is my bonus structure going to look like if I push on this?
What's my promotion package going to look like if I push on that?
Or is somebody going to come and nix my promotion?
And you know, those are also huge factors and we don't have the right alignment of incentives to do security.
Right.
Because the cost of.
Oh yeah, they're always giving us false alarms is huge.
But as you said, what happens if it's not?
Because if you look at root cause analysis for large reaches, the signals were there, the tools detected it.
It was just that it was a needle in the haystack.
Right.
Okay.
In particular, in day and age where security teams get kind of like, they don't grow, they shrink.
Right.
They get axed.
Right.
And then some vendor were just like, oh, sprinkle our magic dust on your cc, man.
We got to solve all your problems for you.
Right, Right.
Yeah.
I mean that just pitch for Spice Labs for a minute.
I mean that was actually part of the original vision.
And I expect that we will evolve the product into the original vision, which is not only building the merkle trees of post build artifacts, but associating those with deploy logs and having that then gives whether it's an AI doing the triage or a Tier 1 SoC analyst doing the triage, they all of a sudden have an understanding of what was running on the machine at the time of the indication of compromise.
And that helps, you know, hey, you know there are PHP vulnerability bots out there that just probe everything constantly.
Oh yeah.
Oh yeah.
Run a web server, you'll find that.
Yes.
And so it's like, oh yeah.
But there was a Java app running on that I can close this ticket.
And if you have an understanding of what the system composition is and what the libraries are, the context gives you enough signal that you can deal with the near infinite number of IOCs that come into every security operations center constantly.
Yeah, we haven't even started talking about the whole package ecosystems around this because that's a whole different kind of worm, right?
Yeah, well that's like, okay, how do you deal with the supply chain?
And once again, that pitch for the company and the technology that we have, all of our Merkle trees are stored in a graph database.
For example, if you find a rogue thingy in your virtual machine or in a Docker image, you can actually ask the question what other images or what other VMs is this rogue thingy in there?
It's just database query that allows you to then track things down much more quickly.
From a for everybody who lived through log four shell.
If you have a full inventory of all the artifacts in your company, you can just run a query saying which of These artifacts contain log 4J versions 2.1 through 2.16 and you get the list.
Yeah, yeah.
But it gets more, but it gets more complicated.
Now Tickle web where git action in particular and CI generally has become a much bigger part of attack vector.
Right.
There's like people treat pinning.
I mean we all know what to do, but nobody still does it.
Right.
But that's actually why looking at the post build artifacts, that's actually what was built, not what your tool says it might have built, which deals with vendor stuff.
And this is actually what we've seen a lot with, especially with Bouncy Castle.
It's not necessarily always specified in the maven or gradle files.
Sometimes teams just literally copy a couple of bouncy Castle files into their application because that's the cryptography they're using.
And the C bomb generators that just go off of maven or gradle built sboms are not going to find those.
Whereas looking at the post build artifacts and knowing what the hash values are of those particular classes allows us to actually look at the ground truth rather than looking at an approximation.
Sorry, sorry for the product pitch.
No, but it's an interesting problem in general because I mean this is very much not a solved problem.
I don't think anybody who's pitches that they have a solutions problem, honestly, they're fluff very punished.
Like moving.
It's hard.
It is freaking hard.
But this gets into inherent versus or intrinsic versus extrinsic identifiers.
So if you think about a package URL, that's like the address of your house.
Yeah, that was something that was assigned by the city.
And, you know, if you live in the uk, it may change from time to time, or so I'm told.
Whereas the longitude and latitude of your house.
So the.
Your address is an extrinsic identifier.
The longitude and latitude of your house is an intrinsic identifier that does not change.
And being able to map between the two is something that gives a lot of power, because the extrinsic identifier is something that humans understand, can manipulate, can work with.
That's why you type an address into Google Maps rather than typing a longitude and latitude internally.
There's a mapping between the addresses and longitude and latitudes.
Yeah, yeah.
And, you know, we look at the problem very much the same way, which is you need both.
You need the package URLs, because that's how the CVEs are indexed, etc.
But you also need the ground truth of the intrinsic identifiers.
And being able to map between the two is very similar to the power that Google Maps gives us.
Yeah, I like the analogy.
Yeah, yeah.
Maybe we should save the hashing story for another day, because that's a different problem as well.
I don't know how that even impacts encryption.
That's a different story.
Over time.
Yeah, yeah.
I hope really educating for the listeners and watchers of the podcast.
I really enjoy.
So thank you so much for coming on the show.
Really very much appreciate that.
Well, thanks for having me.
It was a wicked fun conversation and I might have to have you on my podcast at some point so that we can.
I would love to.
Cool.
Anyway, have a great day.
Thanks, you too.
Bye.
All right, you are fully uploaded.
Found an error or typo? File PR against this file or the transcript.