PQC in the Real World: Crypto Agility, Traffic Analysis, and the Road to Quantum

Sparse pickins. How's everybody doing? >> Good. >> All right. How many of you are familiar with the all the cryptography stuff going on in the world? Anybody have any idea about it? >> Anybody know what Qday is or heard of Qday? we're going to talk about it. There's some really interesting um migration patterns that we're going to have to do inside of cryptography if we want to be secure kind of going into the future. And it's not wait until 2035 to get it done. It's start now. And there are actionable items that you can do in order to do this. And it's not difficult. Now, the math is not something I'm going to dive into, nor do

I expect you to dig into it unless you're a mathematician. Right. So, we're going to dive into uh postquantum cryptography. So, nice little quote. Cryptography never dies. It just gets factored. Who am I? Uh my name is Charlie Goldner. I am a penetration tester. I'm a student. I'm leader. I'm a dad. Um kind of where why I'm wearing my dad shirt today. Celebrate Halloween. I got my MSISC from SANS. Edu. I've got my GSSE. All the obligatory fun stuff. Um, I work with some other amazing hackers at counterhack and I'm a work with SAS sometimes. All right, let's talk about cryptography today. So, I'm sure hopefully everybody understands what asymmetric and symmetric cryptography is. So, your

asymmetric cryptography oftentimes known as like your public key encryption, public key infrastructure, PKE, PKI, right? Those kind of terms and terminology all wrap around asymmetric cryptography. Then we've got symmetric cryptography, which is your shared key. Like I have the same key that you have. You can't tell if I'm actually me and I can't tell if you're actually you, but we both share a key. Now, we use both of these in conjunction together today in order to communicate all over the place in lots of different technology stacks. Now, your classic asymmetric cryptography systems are all based on some sort of math. Um, typically with some large numbers, oftentimes large prime numbers, which is really the threat. In symmetric

cryptography, you have a choice of aes, and you pick the bit size or your flavor, kind of like ice cream, but you get vanilla, and you get more vanilla, and then a lot more vanilla, right? So, 128, 192, and 256. pretty easy. Now, there are two quote theoretical algorithms um that are out there or their their algorithms themselves aren't theoretical, but their application and their effect on cryptography are really the theoretical part because there's no quantum computer to test them on yet. Now, Grover's algorithm provides an attack buff on symmetric cryptography. This one's not as big of a concern because we can pad it out, right? So your AES 256 ends up being like AS128.

So it has the bit size of what you're using for AES or symmetric cryptography. So if you're using AS128 today, it's really AS64. And so it's time to move on and go up to 256. Almost all of your modern systems are going to support that and you'll be fine. That one's not as big of a concern because it's an easy switch. Now, obviously, you want to test your systems out before you make that migration. This is the one everybody's worried about. Shor's algorithm. Shore Shore's algorithm. Well, back in 1994, um, he discovered a very efficient quantum algorithm that could be used to solve those large prime number problems on a quantum computer. Now it's still

again this is still theoretical because there's no quantum computer that can be that this algorithm can be tested on but it posits that all of our asymmetric cryptography that we're using today is going to be broken everything RSA ECC diffy helman now this is important because what's that initial setup and an encrypted connection the asymmetric And so if that's broken, I know what your shared key is, your secret key that you use in your symmetric encryption. This is the problem. Now, this also posits that it needs to have a cryptographically relevant quantum computer. Now, on the bottom right, um you can try and emulate this. I pulled this down from Google. They have a some Python

code that goes through and allows you to build out trying to factor prime numbers and can't do very large prime numbers because well our classical computers can't really do that very well but you can do small numbers and start factoring them out pretty easy. They give you the full code. You don't even need to worry about anything until you trying to factor large prime numbers and then it's not going to work. Now what is a cryptographically relevant quantum computer? A system that can actually factor those large values that we use today for asymmetric cryptography. Now there was a paper that came out uh I believe it in 20 not too long ago um by these two gentlemen Gdney and Eckers.

They said you need 20 million physical cubits in order to break 2048 RSA. Now, those physical cubits are made up of logical cubits and like it's just a lot. We're nowhere near that today, but it could happen any day. They can make some sort of breakthrough, etc. Now, quantum computers really aren't doing that great just yet. Um, you know, if I asked you to factor the number 21 into two prime numbers, what would you get? Three and seven. Those are two prime numbers. Pretty pretty easy. It takes a quantum computer a little bit longer than what you just did, just a little bit. But that's the best it can do as of the research that's been

published. Obviously, all of that's in the public realm. And what happens on the private side, who knows?

Now, what has N standardized? What are the different types of kind of postquantum cryptographic algorithms in place? We have two different avenues. You have your digital signatures and you have your key your key exchange or key encapsulation mechanism rather underneath your chem. You'll see that term quite a bit with the postquantum cryptography in the algorithms that's always specified now. And same thing for your digital signature algorithms. So you'll see DSA and chem. Those are that's really what the two nomenclatures are all about. Key encapsulation, digital signatures. And they've stuck to that with the naming convention of all these new algorithms, which is useful. It's helpful for us as we're doing some implementation. Now, underneath your key encapsulation,

you have two what you could say are ma the math behind it. The math behind the standardized ones for ML are module lattice. So in the name, it tells you kind of the math behind it. module lattice key encapsulation mechanism your codebased we'll get to that here in just a little bit there's a um there's been an approval a provisional approval at least they still have to draft the standard for HQC it is what's known as a codebased key encapsulation mechanism there's another one that's been around since like 1970 1960s it's been around a long time but it wasn't used for this and we'll get into that here in just a little while on On your digital signature side, you

have two types. You have your stateful and your state lists. There's a big difference between the two and what their use cases are for. Now, all of the kind of algorithmic back end of each of the standards. So, MLCM, it's Crystals Kyber, Crystals Dithium is MLTSA. Um, Sphinx, it's a stateless, so SLH, stateless hash, and then it's DSA for digital signature algorithm. Now, I don't know what they're going to name Falcon. Falcon was also been approved, but it still doesn't have a standard or it does have a standard, but they haven't come up with like a a name, so they just call it Falcon. But that might change. Things in this space change pretty often.

Now, what is module lattice based? Everybody seen that little dot game where you connect like one line and everybody has a turn to like connect a line and then you fill in a box. That's kind of like what a lattice looks like except instead of two dimensions you have like thousands millions of dimensions. Now in our minds that's kind of implausible but according like for a computer that's not because it's all just algebraic equations. It's just multivariate huge list of variables and so it's all based on vector math. How can I get to a specific vector to identify the secret key? And they've added in some error. That way it's a little bit even more uh

more difficult for a computer to guess what that end vector or that answer to that problem is. That's that uh core task that hidden noise. It's very very difficult. Now your module lattis base again your ML Chem and Falcon um MLDDSA. So both of the crystals algorithms are module lattice based. And the reason they started going with different types of math and different types of algorithms like module lattice based and codebased is because well these things we're unsure. We're not sure if these things are going to survive out in the wild.

Your stateful hashbased NIST actually standardized two of these. Um they're called XMSS and LMS. They're all both of these um are based on what are known as Merkel trees. Anybody know what a Merkel tree is? Anybody ever heard of Bitcoin? So, Bitcoin uses something like this. It's a Merkel tree structure. And so, it's all based on how a hash gets created. And it's just a tree full of hashes. And how can you prove that a hash was done or you know the work was done? How can you prove an authentication path? So these um both use that same type of mechanism and XMSS just adds some XOR into it. Now the difficulty with both of these are they

have to keep track of the state. Now what that state means is there's in that tree you have a path and in that path that's one key or a leaf that's a one-time key. You can't use that path again. You can't use that key again. that path equates to a key. Now, if you can't use that key again, well, I have to keep track of all the keys that I've used. So, that's why it's known as stateful because you can't reuse a key. Now, it's not meant to be a everyday use type of solution. This is meant for things that are longived, not anything that you need to reuse every day. It's not useful in like a TLS connection.

That's why these aren't primary in what all the postquantum um items are going to be in the future. All the postquantum algorithms for general use. It's why uh Sphinx was approved as a stateless. Your stateless um still well I I take that back. stateless um not stateless as the primary use. It was um diliththium as the primary use. A lot of terms. Now this is another digital signature algorithm here under your stateless for sphinx. Sphinx uses the same mechanism. It still uses Merkel trees, but it doesn't have to keep track of the state of what's happening within that Merkel tree structure. And so it can just generate a key and now that key can be

used and it can move on. Um, so all that state means is like if a system's resident and it's living and it's online, if that system gets torn down and then built back up again, um, you've lost track of the state of the keys that you've used. And so if you try to use the same structure, it's going to break or you know, somebody could break that cryptography that you're leveraging. With Sphinx, you don't have to worry about that system getting rebuilt because you're not keeping track of the key every time. couple of your codebased um HQC. This is the one that has um it's a draft standard right now. They're going to probably publish the actual FIPS

standard within the next year or two. It does take a lot of time for that to happen. HQC is going to be the backup to ML Chem. So MLCM is going to be the primary as the postquantum cryptography for key encapsulation. Now, the one that's been around since like the 1970s is classic mccles. Classic mccleles, you know, the biggest reason they um haven't really where they didn't really choose that, I mean, I'm not on the board. I don't know what the reasoning behind this, but you can theorize um classic mle uses huge keys. I mean, they're extremely big. You think an RSA 4096 key is large. The classic mccleles like at a level five of

security would be like a megabyte in size or larger like it they're very very large keys and that's why it's it's not very efficient but it's very secure. This is all um built on error correcting codes. So you got to sort of try and find the message based on what was delivered with that error on top of it. So essentially it looks like this. sent you a note hidden in an enormous crossword puzzle. Messed up a few letters, but if you know how to decode that, then you can get the message. Now, I had chat GPT um generate this image. Actually had AI generate almost all the images in here. So, some of the letters don't look right. So, still a

little jumbled.

Now, there are different security levels for each of the algorithms. So, they each have a specific little variant. Um, your security level one is essentially where most people are at today with their classical algorithms. You're using AES128. And so, the postquantum equivalent is going to be your MLCM 512. There is some conjecture that it's not very secure even with MLCM at 512. I have seen some research within the last couple months that uh it's not super secure. HQC 128 and then Falcon 512. Now, if you want to get that level five security, you're thinking of like, you know, I know we're kind of in a government space or near government facilities and you're thinking about

things like information that has to last and be secure for a very long time. you're probably going to be looking at a level five of security. Your key sizes do increase. Your cipher text and your plain text do increase in size. And that's one of the big concerns with moving to postquantum cryptography.

Now, there are other candidates that are out there. Um, classic is one of them. you know, depending on where you're at in the world, NIST standardized some and a lot of people use the standards that NIST specifies, but not everybody agrees on that. So, like in Europe, they still think like some of the other candidate algorithms could be used instead or they're going to include them to make sure that they're available for use. And really, it's just not spreading yourself so thin on the algorithms that are standardized. So, we have other algorithms to use in the event that something happens. Digital signatures, there are a ton. The key encapsulation side, there are maybe um I don't know the exact number. There

was like 10 or 12 candidates. There wasn't very many, but digital signatures, there's probably 30 or 40. Mayo is one of them. Um the math problem behind it, it's kind of funny. Um it's a pun on the name. It's the oil and vinegar problem. It's kind of ironic. What about the rest of the world? There are standards that are out there um throughout the rest of the world on what is chosen or what could be implemented. Um ISO has a couple of standards for and this is where I was mentioning you know the froto cam and classic mccleles you know on the international stage like in Europe they appreciate the fact that these have been around for a really long

time and they've been proven at least classic mccleles and so they think that one is is still a solid choice um in the EU the ES or excuse me the ETSI they published some information about migration um in conjunction. So it was like the Dutch, the Germans, and the French. They all came together and um collaborated on this. And the Dutch actually published what's known as the PQC migration handbook. I'll show you what that looks like here in just a little bit. Now, is it really being used in the world? Well, it is. Apple started using it over almost two years ago now. Signal migrated over two years ago. Now, they're not using strict postquantum cryptography. They're using

like a hybrid approach, and we'll talk about what a hybrid approach is here in just a little bit. Google's been doing this for quite a long time. They've been part of the standardization process and testing a lot of these items. They use it internally within their own infrastructure. Um, Microsoft has finally Microsoft's been doing a lot of research in this space, but they finally released some tooling for Windows in this year. AWS has their own cryptographic library that you can leverage and you can actually uh start creating keys within AWS KMS that are MLKM. Open SSH um they took a while to get on board. You know open SSH I think right now is on version 10 something. Um but

9.9 which was released earlier this year probably around summer they finally started supporting MLKM as a key exchange or key encapsulation mechanism. the PQC capabilities matrix. Um, if you Google that term, um, you'll come across a website that has the capabilities of all the different types of libraries and solutions that are out there and what they support and what they don't support. It's really useful tool to have on hand. What about those mitigation options? So, what can you do today to get ahead of the curve? Well, you're trying to mitigate what's known as the harvest now, decrypt later, store now, decrypt later. a couple different terms that go with that. You know, it really depends on what your

risk level is. You know, if you are in that government space or you're providing cryptographic material to others, you're probably going to need to think about switching now. And we'll go through kind of a a timeline for depending on what you do as far as work or where you work. Q day. Qday is is supposedly that, you know, it's a kind of a coin term like a lot of things in our industry, but Qday is the day that a cryptographically relevant quantum computer comes online and can break our current classical asymmetric cryptography. And so you want to avoid having to make that emergency change at the end because you're going to be well behind the power curve.

You've got three mitigation paths um to choose. You can go QKD which is quantum key distribution. You can go full PQC never go full PQC or you can use a hybrid approach classical and PQC together. Option A. Now quantum key distribution um you're you've got quantum key distribution devices in different locations. There is a physical limitation between these items. You have about a 100 kilometer distance. They got to be connected via fiber, lots of additional hardware. Um, the biggest issue with this is there's not a lot of good standards or standardized way of tackling this problem in the KQD space. There are solutions out there, yes, but there's no like standardized like here's how you keep this solution secure.

Here's how you should set it up. Um, even the underlying the security of it is still suspect. So really you've got two mitigation paths. Go full PC. Now you're depending on unproven cryptographic schemes or cryptographic algorithms. Now that's not necessarily true. You know unproven they've gone through the standardization process. You know people a lot smarter than me. You know mathematicians, cryptographers, cryptographic analysts, cryp analysts. They've gone through and done, you know, a lot of the leg work to try and verify that these things are solid. However, they haven't been in the real world in use in mass. And so that's that's that's part of the problem. Now, if you want to go full PPC, and

this goes for hybrid as well, you have to be able to have what's known as cryptographic agility, which is being able to switch really fast. because if some new novel of vulnerability comes out, well, I can't be like, well, I'll just wait till somebody else figures it out. It doesn't work like that. Now, you typically don't need any additional hardware with postquantum cryptography. It's really a software change. As long as your software stack can support it, you shouldn't have a problem. Hybrid PQC. This is the one that most people recommend because you're using what you already know, what you're already using in combination with the new stuff, the new kid on the block. Maybe I should put like new kids on the

block on there. So, it's the classical and postquantum cryptography together. when you do that asymmetric key exchange instead of normally when you have kind of one validation done on the exchange there's two there's one for the classical side and one for the uh postquantum crypto cryptography side and after if both of them don't agree or both of them don't pass that test then that assumption is thrown out. Now both the full postquantum and hybrid can increase the complexity or can increase the attack service due to the complexity of the implementation because there are a lot of different things to take into consideration. Again, this one also doesn't require additional hardware. Typically, it depends on your your types of systems

that you're using. Now, what is cryptographic agility? Now, there are some kind of definitions that are out there. Um, the postquantum cryptography migration handbook from the Dutch has a really nice, it's pages long, but really the way I look at it is decoupling your cryptography from the infrastructure. Instead of having, you know, cryptography or anybody worked with networking gear before, you know how you can have the crypto mod inside like your Cisco device or your network device? That's no longer a thing. I don't need that anymore. There's actually a protocol um called skip and skip allows you to request a key from a key provider and then use that key in your communication. And so you don't have to have the crypto

cryptographic module on your device anymore. So it's like an API and so it's decoupling that cryptography from whatever the system that needs it. That allows you to make some changes very quickly. It's instead of using a monolithic architecture, we've decoupled it. There are some commercial solutions out there. I just did a research on one from a company called Quantum Exchange. There's another company out there that does this called QS Secure KU and then secure. Both of them offer this type of capability, right? So you plug in a container um plug in you host a container um in the cloud if you want to do it that way. Your network devices can also host containers and that becomes

the key provider for that device. So having some agility and being able to migrate quickly in the event of an issue on the classical side or the postquantum side. Right. So do you need to switch? Well, there you that uh postquantum cryptography migration handbook, the PTC migration handbook from the Dutch. I use some of the information from that to come up with these items and it's actually really well done. So, they have uh the first or kind of three tiers. You have your urgent adopters. So, if you're worried about long lived secrets need needing to keep it secure for a long time, you should already be looking at switching if you haven't switched already. your regular adopters. You know, these

are most businesses will fall into this category. They don't handle any types of sensitive data. You know, sensitive data is I guess relative depending on where you work and what you do. But infrastructure type data, critical infrastructure, government secrets, national secrets may be financial data depending on who you're doing financial transactions for. Cryptography experts. Now you think of like the people who provide the capability for you to host your infrastructure on and you consume things like cryptographic algorithms from them. Your cloud service providers, the government agencies that provide cryptographic primitives to military units, things like that. How do you switch? Well, you first need to understand what you have, what you're using. It's doing an inventory all your

supply chain dependencies and the software you use throughout the entire life cycle of that device or whatever it is. Um it's just like when you have your computers, you need to do some sort of asset management or configuration management on the systems that you own. It's the same for cryptography. So it's establishing some sort of asset management or configuration management for your cryptographic primitives that you're using. Establish a policy if you don't have one already and then review it as you go along. Understand what your risk level is. So conducting your own risk assessment. Um there are going to be some costs of migrating. Some of them are operational and so sometimes you might have some downtime in order to you

know implement something. Not everybody's going to be able to support it. So you have to have some fallback mechanisms. Are you bound by any regulatory requirements? Do you have to switch by a certain time? Are you supposed to use a certain type of algorithm? Um the NSA has their um I think it's what the CNS SI 2.0 where they establish like what al algorithms you can use then collaborating with others right anybody want to see this in real life

so there's a couple things uh I want to show you uh the first one actually before we do that one let's look at the postquantum migration handbook so this is the um PQC handbook from the Dutch it's very well done um it goes through you know literally almost everything I talked about in depth quite a bit um asset management migration planning execution um developments throughout the and then looking at the different primitives that exist. Oops.

They even have little process life cycles. So again, you can find this online. Just look for the PPC migration handbook. It's a good book.

Now there's a project called open quantum safe. Now open quantum safe

has done a really good job of making this accessible to the world. A lot of your commercial solutions that are on the market now leverage the cryptographic library that these folks have built. It's called libqs. So libqs um it's all open source. It's all you can review the code. They've got CC code implementations, right? So if you need like the actual source code of how to implement this in a software stack, you can do that. They have their GitHub repos, quite a few actually. Um the library itself, so libqs, they can you can use as a provider to open SSL. And then they've got some demos. The demos are really nice because you can stand this up kind of locally without

having to worry about anything. You don't have to go over the network anywhere. This is libqs. Talks about all the different fun things. Uh the provider, the demos, um they've got different technologies um available here for you to stand up and leverage postquantum cryptography using that software stack. So, if you're running Engine X, you want to run it in OpenVPN, whatever it is, they've got some demos for it. Now, you got to take what they give you with a grain of salt, and you're going to have to do some troubleshooting. I've had I spent many hours trying to figure out why something was broken, and it was really because the naming convention has changed from

using a dash to not using a dash or vice versa. It's ridiculous, but again, these things change quite a bit. or you can use their pre-built containers and you don't have to worry about it. So their pre-built containers um they have curl, they have all of those um items that are listed on that demo site and and then some. So pre-built containers that allow you to stand up a specific capability and then go actually do it. They have a test site where you can test your implementation um or even use their stack. So it's a TLS 1.3 site and they walk you through like here's how you can test it. You can do some packet captures. Now

that's one of the biggest problems that you face with what like dealing with this technology is not all of the software that you have and that you're normally used to using can understand it yet. So one of the demos that they have is a custom compiled version of Wireshark which we'll see inside of the demo here in just a sec. So, I have uh two versions of Wireshark running. One I can just pull up a pcap um in case things go arry. The other one I'm just going to capture traffic live. So, we're going to This is running in a container and I can't zoom in. That's sucks. We'll see that in here in just a sec.

Right. So, curl um if you want to go look at like their website and curl a specific algorithm like they give you they have a different algorithm hosted on each port. Each one has a specific signature. Each one has a specific key exchange mechanism and so you just curl that port using their container which they give you on the same site and you can see it implemented. So, I can go hey curl Let's uh make sure Wireshark's listening. I also am storing the SSL key log file so we can actually look inside the encrypted connection.

This one's going for MLM 1024. And there's the communication. No big deal. Now, inside of Wireshark, if I go look at the actually before, let me go add in or inject my secrets.

Oh, I had to restart curl. Um, so I have to do that key log file again.

Oops.

That was not working. We have a backup plan.

So, in this communication here, um, what you're going to see in Wireshark or things of that nature, I wish this could be much bigger. Um, let's see. Oh, this one will zoom in. Why would the other one in your non-custom compiled versions of Wireshark. All you're going to see is an oid instead of the actual algorithm that's being used. That's part of what you do when you you're building a custom compiled version is you define what that oid refers to. So if you're seeing things like that, you can there are lists out there. The IETF actually has a list of the oids so you can identify what the algorithm in use is. So in this

one, the certificate being used is the MLDDSA certificate. So that web server certificate on the web server is signed using the MLDDSA. So that's a security level five certificate. Now in my uh client hello and my server hello

Notice how some of them are show up as unknown. It doesn't know how to understand those because the oid is not identified.

on the SSH side. Um you can use this in SSH as well your um SSH config. So if we look at our SSH config just really quicks SSH SSHD. Uh so this SSH config only leverages postquantum crypto um cryptography for key exchange. It's the only um key exchange that's allowed. No classical is allowed. So it's using either hybrid or pure. No, no classical at all. For the host key algorithms, it does the same. Although at the end I put in um RSA and ED25519. So if you still want to leverage things like the classical specifically, you can. Um this is also a uh their lib not lib but open quantum safes open ssh build. So you have all of your hybrid pure and

then classical algorithms there and then you can create your keys and build them out and leverage keys for postquantum cryptography. Um, there is a tool that I built. Really, this is just Python that iterates through the SSH key gen command and builds out all the keys.

If we look at the size of each of the keys, so based on the algorithm, here's what the the bit size of each of those keys ends up being and then the N security level that equates to it. So, if you want to use like a security level five SSH key to establish a connection um depending on the key size, if you want to keep it smaller, your best bet for um a security level five is to use ECDSA with NIST's P521 elliptic curve and then Sphinx Shaw 2256 F simple. And these names get really convoluted and they get very long.

Now that I have a set of keys, I can just use them. So I have inside my SSH directory, I've got a security level five key here. I've got another one here. One is hybrid, the other one is not. And then I've got um actually no, these two are hybrid. This one here is strictly postquantum. So I can say SSH pick a key. Let's say ID Mayo2.

It works. It doesn't take that long to make that key exchange. Now granted, it's only going to local host, but both sides would have to agree. And now I've got a postquantum protected SSH connection between two systems. So it's not super difficult to get this done. All right. Anything anybody else wants to see questions? Yes. >> When do I think few days going to arrive? You know, um like if you follow what's going on, you things happen so rapidly, especially with AI. Honestly, I don't even think 2035 is going to be a target. Um, yes, they're pouring a lot of money into this, but I think the capability will come out to us a lot later than it

actually shows up. Um, because things are going to happen behind closed doors before they go out into the public because of national security reasons.

Yeah. Um, if you're interested in like actually doing things on a quantum computer, so speaking of IBM, IBM has a um, a program um that you can get into. is called Kizkit. Kiski T. And you can actually code quantum circuits and have them run on a quantum computer. And it's free. It's actually a really cool community. You build out your code in Python and then you host it up there and you get some time. It's like a shared space where you can run your code on a quantum computer. All the major cloud providers have a quantum computer or quantum capability inside of them. Um, so it's not cheap, but you can run some quantum workloads

in there as well. Yes, >> I can. Yeah, absolutely. I can post the slides.

>> Okay. >> Yeah. So, besides, I'll post them tomorrow. Yes.

That's a great question. Um, so does it affect TLS fingerprinting? And it does because your your the keys that you're using change. And so the the fingerprinting is all based on that key. So if you're using like Jaw 3 hashes to identify specific targets, then that hash is going to change significant. I mean, not significantly, but it'll change. It's just like any if your key changes, your fingerprint changes. Yeah. So your your hashes will definitely change. >> Yes.

which so you can establish like on your server what PTC algorithms you want to use like on your HTTP server. So like in the engineext configurations um that they have posted you can say I only will support these these algorithms. Um so you can specify that just like I did in my SSH config. So where that I will only accept these algorithms and nothing else. Um

Yeah.

The algorithms themselves. So it's it's the primary standards. Um the primary standards are going to be kind of the way to go. It's using ML Chem, MLDDSA, those are the ones that are like the general use and everything other all the other items or all the other kind of ones that are being standardized or even candidates, they're just backups. Um yeah, for general use it's ML Cam and MLDDSA. Yeah. >> Yep.

Right.

He

I think you're absolutely spot on. Um I think it is more of a nation state thing right now, but I think also it has to depend on or it does depend on um who you support within your organization. Like if I'm if I'm AWS or if I have my stuff hosted in AWS and I'm in GovCloud and I provide services to the DoD, I probably should consider looking at this sooner rather than later. Um, if I'm, you know, a little software company that doesn't do much besides support a couple of different states within our location or our area, you know, I wouldn't consider it like a super big priority. Um but if you're if you are supporting like

government contracts things of that nature and you're hosting your stuff in clouds and you know one of the things um I looked at when I was testing that solution from quantum exchange was they plug into the WAN side that was where the kind of big migration pattern starts as you do it from your WAN connection. So sight to sight everything internal might still be just fine. Might still be using classical cryptography which is fine. But on your WAN connections in between sight to sight where it can be captured that's really where you got to be considerate of what encryption you're using. Other questions.

All right, there's my contact information. My GitHub is kind of sparse. Most of my stuff is done on the private repo side, but if you have any questions, you can reach out to me um via email uh or on LinkedIn. LinkedIn is probably a little bit easier. Thank you very much.

Take a pick.