Implementing Post-Quantum Cryptography: Modern C++, Migration, and Silicon vs. Cloud | RWPQC 2026 S2

Hinzugefügt: 2026-05-19

[00:00:05]Uh our next talk is from Anjun Roy from Radbound. He'll be talking about beyond portable C. Uh please welcome Anjun.

[00:00:16][applause] >> Hello everyone. Good morning.

[00:00:22]So yeah, I'll be presenting uh grand portability rethinking PQ's implementations with modern C++ patterns.

[00:00:31]Um uh I'm Aendro. Um I'm a software engineer with deep knack for doing applied cryptography mostly implementation side of things and optimizing it. As with Polygon Labs, I spend there a couple of years. It's a scaling startup in the Ethereum blockchain ecosystem. And uh then I spent couple of years at PII in Abujabi.

[00:00:53]Right now I do soft engineering at a project yet another startup in the Ethereum blockchain ecosystem and I am along with that I'm also pursuing PhD at Radford University.

[00:01:08]>> I'm sorry can you hear me clearly?

[00:01:16]>> Yes.

[00:01:18]>> Uh all right. So yeah, so uh December 2016, NIST asks public to help future proof electronic information called for BQC.

[00:01:28]Six years later, July 2022, NIST announces first four quantum resistant cryptographic algorithms.

[00:01:35]Two years later, NIST releases first three finalized postquantum encryption standards.

[00:01:42]And this is me. 2022 September [clears throat] I wrote the second commit of the MLKC blog post implementation that I'm going to present about 6 months later 23 February I wrote to the PQC mailing list announcing that I was implementing Kyber delthium falcon and sphinx club and this is a screen capture I took about two weeks ago uh so in last three and a half years it saw about 523 commits the MLKM syllables constraints per implementation the full MLKM implementation with all security levels and everything with 1260 lines of code while MLDDSA it's a little lesser commits 392 and I have been also developing that for the same duration three and a half years and MLDDSA the full implementation including all security levels prehashing mode everything it takes uh 2004 lines of code.

[00:02:47]So what is this MLK and MLGs with C++ libraries the two separate of FIPS 203 and 204 they have zero third party dependency they are fully header only they have they are fully compile evaluable that means that you can evaluate the full MLKM all the algorithms or MLGSA given that you know all the inputs of the program compile them itself it can be useful we'll see that thing in a while and therefore N SVB compliant. So all the C cat test vectors there we pass all of those and they are constant time operation at least we try to make them constant.

[00:03:27]ML cam it supports all three security labels and also MLDDS supports three security level it supports a prehancing mode also but it supports it with only shat function not the S 2. Why? We'll see in a while.

[00:03:42]The question is why C++? Uh but why I say that it's not just C++ it's modern C++. We use a lot of new features from the new C++ language and then try to incorporate that and then we try to get some better guarantees and programming better type system guarantees in the model C++.

[00:04:02]So what what do you use in model C++ state span is one of the so we do not use anything called draw pointer plus size pair which we generally see in traditional C++ or maybe C code bases instead it's wrapped in step state span we choose to use const which means actually constant expression over C style macros and there is a new addition called recourse expression that was added in C++ 20 we use that thing for Compile time parameter validation and one of our goal is to sort of move all the things that you can move to compile time rather than keeping it at runtime. For example, parameter validation that could be done at compile time and definitely we use a lot of templates. It has been there in C++ for a long time.

[00:04:51]So this is what the speed span based API looks like. So you have state span, you put the data type and you put the length. So the length and air type both are part of the type system itself. So there is much better introspection that the compiler itself can do on that thing. So like you can just see what is the public key the signature and you know sort of what is the length you cannot see it here it's written in form of constant but yeah you get the point and so the interface looks sort of cleaner compared to this is a raw pointerless interface you have like two const for every word one con is for the data type another for the pointer and then you have the restrict compiler extension being uh underscore restrict because restrict itself is not a keyword in C++ language.

[00:05:43]It's a keyword of the C language. So but there there's a compiler extension available in both GCC and plan and we used to have that thing long before uh we move to state span rest API but state span doesn't only give you the string defense see here we have the paired secret that is being derived for by doing encapsulation which is supposed to be 32 bytes but if I change it to 31 the compiler is going to complain So you naturally get uh like you cannot pass a wrong value or wrong size um input to it. So you get much better compile time error reporting. So harder to misuse API with speed span you do not have to do any more point. Uh so you can just use subspan and the subspan you can cut the subspan at compile time. So because we are using the template parameters they all resolve and program compile time.

[00:06:44]And you see all the offsets are being calculated in con HP because they are all constant expressions meaning they're evaluated at compile time and we can do that thing at compile time and if there is a mistake that if you have 32 bytes and you are trying to get 30 last 33rd bite or something it won't work the compiler is going to compare not a runtime problem anymore.

[00:07:07]Now here is another example of the compile time bound check. So on the left hand side the Z value on the line line number 128 I increase it by one. So for that reason the right hand side compiler that's going to complain and all these errors are coming from the editor. It's just a clangd u language server uh client that's giving me this error. So if you just compile that thing you'll get also the same looking error.

[00:07:37]State span is not a silver bullet though. So here in this case I try to cross a steed span like that I allocate 32 bytes but I sort of say that it's 33 bytes and I can do that thing I can cross a state span and the compiler will not be able to catch that.

[00:07:56]So that's what it shows. So so you see that the assertion or the encapsulation line is not failing or it's not throwing anything.

[00:08:05]But um there is a way to harden that binary if needed because this is a like classic problem that you can allocate a 31 byt buffer and you can pass the size of 32 bytes and the compiler has no clue and then there'll be a runtime failure definitely if you try to access that and if you enable assign address but you can also enable lipy assertions or in the clank there is a hardening mode we can enable that in the first case it doesn't catch that because we don't did about that in the second case if you just compile the program it will abort.

[00:08:40]So um so okay let's go with the compile time evaluation so we can compute any output of MLKM or MLDDS at the program compile time given that all the inputs must be known at the program compile time also and one thing to note is that because MLKM and MLDDS they are very large algorithms that means they have a lot of steps the compiler needs to actually execute all the steps to give you the output. So we have to in a lot of cases we have to increase the there's a compiler parameter called constr steps that we have to bump up to a very high value could be multiple millions also this is an example of what I saw in MLM 512 being evaluated at the program compile time. So in the top part of the program line number 9 to 12 you can see there are couple of cat vectors written there and then line number 39 in the body of the test there's a static also.

[00:09:33]So static assumption evaluates it at compile time and just ensures that um the that it's true right the condition but if I change that shared secret value to just a one nibble of it the last one then you'll see the static assertion start to fail and it happens almost instantly because if you see the body of the function that eval MLK can that thing getting executed at program compile time and this is executing in the so this is a good feature you have so constr const xr uh this from the C++ reference website constru it's constant expression what it means is that con xr doesn't necessarily need to get evaluated at program compiler it can't given that you have all the inputs so you can use that same construct function you know definitely at the runtime and it will not complain anything the compiler will not complain but there's another thing called con eval conal is a function are something that needs to be producing an output at program compile time itself. So const it must be evaluated at program compile time. So parameter validation is a very nice feat for constant evaluation. So see the function uh check encapsulation parameter that is declared as con to val because we know all the parameters at program compile time itself and we can validate that if you invoke that thing that will be validated at program compile time. If that doesn't get validated the program doesn't compile you get a compile time error. This is what it looks like. How do you enforce that constable function? You use it with a recourse expression that was added in the C++ 20. So you check that thing and if it doesn't compile it fails.

[00:11:23]But for the actual implementation for let's say the intax listen function we want it to be constr the function because we do not want it to be always evaluated program compile time. That's not very helpful. So there is one thing to note as the encapsulation function for it to be constant every computation that it does needs to be also constant expression.

[00:11:45]So hassling MLKM does a lot of hassling and so let me introduce S3. So it is yet another implementation of M script 202.

[00:11:54]It is a modern C++ header only fully constra library implementation of S3 and Turbosc. Uh so Turbosc we implemented there it's in the RFC 9861 and it's actually faster much faster than S3 we have as also say quick detour for S3. Sach I've been also developing for last three and a half years and it's also um another open source project of mine. This is what a compile time evaluation of S3 256 method does looks like. So you take a string hutation ro and you convert it to the bite line number five to 53 bite array and then you do con xpr empty that's the line number 54 and you call the s 3 256 h function on that message by and it computes that end to enforce that thing inside the body of the main function line number 60 you do a static assertion against the expected message types if this translation unit compiles it's guaranted that uh the su 256 implementation is correct but we just do not do that in S3 we take S3 the construct PR capabilities to great next level in S3. So in K computation it could happen at max 24 rounds and instead of hard coding the KA 24 round constants we compute them at program compile time itself. Every time you compile that translation unit, it will be compiled uh instead of having hardcoded. So much less chance of just by mistake changing one thing.

[00:13:32]Uh let's see how does such compare to XCP in performance. Uh so well it's slower definitely 10 to 15% slower. XCP is sort of the state-of-the-art for anything and everything HR permutation will uh in this example I compared it with the Turbosc 128 example but one thing to note about SAS is that um it's very easy to use it's headed only it's plain C++ there is no architecture specific optimizer editions implemented yet and we just use couple of loop and rules and we compile it with O3 and MR native MR native might not be useful for all the cases But at least for this benchmark comparison, we did in case you are interested in SAT, there's a link to the GitHub repository.

[00:14:21]I'll just pause for a moment.

[00:14:25]All right. So let's go back to PTC. Uh okay. So we have the full implementation of the prime field arithmetic for MLKM and also MLGSA implemented uh in constant time. So we can do some really fancy things and we can assert some things are program. So let's say the za value which is a primitive 256 root of unity modulo the prime that is 17 but we could have just kept it 17 written as a hard constant. What we do is that we put another static assertion line number 17 just below it. It exercises that condition that if you raise 17 to the^ of 256 and then do a modulo Q the prime it actually gives you one. So we do that thing and that actuallyes couple of code bugs. First it ensures that 17 is actually 17 and ensures that you can actually correctly do exponentiation which is actually couple of multiplications. So yeah it has a couple of code parts. um instead of hard coding the whole table of 128 powers of GA values which we need for number 30 transform we compile and compute them like I showed for the S three we do not comput we always compute the round constant for h computation so that's one thing well now the interesting part so con doesn't just give you compile time evaluation it protects you from undefined behavior so on the left hand side I'll try to embed an undefined behavior which is signed integer overflow and see on the right hand side it's failing. Now I change it to unsign integer and the right hand side the code block it passed. So what it means is that in the constant expression uh constra function you cannot have undefined behavior like this this kind of undefined behavior let's say integer overflow kind of um undefined behavior you cannot have that.

[00:16:17]So no UV that's a really good feature to have. So what the CP refer whose evaluation leads to any form of poor language undefined behavior. So core language undefined behavior is important because undefined behavior itself can be a very wide thing. It could also include us from this kind of undefined behaviors. it protects us from this uh like the standard setup of which we are more worried about uh sanit trying to access memory out of bounds all those kind of so you cannot have that in a construct function so I asked Gemini 31 pro model to um review the MLM and MLG of the libraries and it came up with this summary a crypto library where the compiler itself verifies correctness no undefined behavior no hidden bugs and every bit proves the implementation matches the specification quite nice. Uh but to to be more serious um so these are two very minimal implementation uh fifth 203 and 204 um it's written plain C++ no assembly um the uh yeah and we do not have any third party dependency and there is no undefined behavior at least the core core language defined behavior and this also and this kind of choices that you make for doing many things at program compile time that reduces the supply chain attack vector We also do compile time self- testing.

[00:17:49]The example that I saw, we test against the need cats at program compile time itself. But that requires us to provide a huge number of constra steps to evaluate that thing because it takes a lot of time. Uh well the one more thing to notice that if there is no undefined behavior uh it's a little bit tricky to scrub the memory uh that holds the secret key material. So but but there's a solution you can do is that you can check that are you in a constex constant or are you not. So there's a function that you can use is const evaluated and then you can put a assembly block because assembly blocks are not allowed or inline assemblies are not allowed in a const function. So if we did not have that thing, if we just put that array fill which is nothing but a mess set uh it would compile just completely remove that thing at O2 even.

[00:18:42]Uh so yeah we we need we can do this kind of context switching that uh when at runtime when being evaluated for the non-construct constant that that will be preserved and the compiler will not remove that thing at the very final produced output and uh so yeah for for us I talking about compile time for us TT is also constant time and we are fully constant time uh we have uh another library that's called suckle which has some small small primitives like constant time selection constant time equality all those kind of things to ensure that they are passing the main compare and the main copy that we use a lot in the MLM the so testing we don't do any new testing instead we do propert testing uh we introduce the random mutation and assert if the property is being broken or is it being preserved we test all new specific vectors when we pass them all and we run all the test against this kind of a matrix assign This is the CL uh deb debug release and release debug info and minimum size release that's the OS the last one and we do that thing in Mac OS and Linux uh Windows has not been uh one of the targets yet and we f them all uh so no you need testing this is what it looks like so we uh to test the primary arithmetic implementation of the MLKM what you do is that we random sample two two values then we do some computation like addition and subtract ract negation and then we uh then we assert the properties are being preserved and we do that same thing for the multiplication uh exponent and division which actually exercise division requires you to do inversion and inversion requires you to do of exponentiation following the pharmaceutical theorem uh and we do that thing let's say 1 million line number nine that gives a pretty good um like coverage and all the code baths are exercised and this is about the uh introducing a c random mutation and then doing that thing. So this is MLKM 768 decapsulation failure test. We introduce a C random a bit flip in the decap before just doing the decapsulation and that triggers and asserts an error and it will actually trigger the code parts for the physic transform needed to do that implicit rejection and we assert that at the end of the function and we pass all the nestbing has been a work in progress. I've been working on the um initial infrastructure setup has been done and so far it looks good but there is more to pulsing because we have to do structure pulsing we do not have to do any kind of parameter validation because we anyway use kit span and kids spam gives us compile time um parameter validation and also you know bound checking so we don't have to do that thing but we have to we have to exercise both both the happy and unhappy code paths we have to embed the knowledge of the MLKM keys and cipher text we not just use three random thing otherwise it never gets anywhere and um we supply initial corpus and we we need to ensure that the corpusite keeps growing and we measure the code coverage that actually the code parts are getting exercise and for better coordination among multiple fuzzer threads we use something called LVM fer has option called so that they can coordinate and put feedback in a better form so using MLK in your project is very easy it's a CC project and you can just use the g repository in a CMake project and it's super easy. In case you don't want CMake, you can just it's just couple of header files. You can just grab them and include and it's all open source definitely and it's all liberally licensed. Uh this is what it looks like.

[00:22:25]Um so this is the dependency declaration at the top in the CC file and you just use that thing you you can use the random set. So random set is another thing for if you need cryptographic seed randomness. Uh so it is the cryptography random bit sequence generator. uh it's built on top of tech uh 256 and or or turbos 256 x and it's convenient for cding for state random right it's easy to use C++ standard template library statistical distribution for example if you want to generate some uniform random integers in the range of 972 it is that would be you can also genate unifor at a report on on this design of this kind of and okay we are almost there. memory uh we take ML as a state-of-the-art implementation and compare against that uh ML native compared to that we are 3x lower um well the reason behind that is that native it's C90 it has some optimized AVX2 back end for doing entity and also the most important the 4x paring part we don't have any of those things this is on x86 uh intel x86 machine running Linux and this is the uh 50 uh on AWS gravit which is an R64 architecture the gap still almost similar for MLM 768 3x difference uh and MLGSA MLGSA also similar the key generation and the verification they're also 3x lower in MLGSA compared to MDS native which is again a lot implementation and it has a lot of very nice optimizations we do not have any of those things yet the signing is way too slow. I guess that will be with the board. Um on R 64 um that the as AWS graviton for machine the performance looks almost similar.

[00:24:39]The question can they become faster? Uh yes there is at least 3x for growth for both MLM and MLSA. The way to do that thing is is sort of known. We can implement ax2 and neonics but we can use that thing in a non-conrict context. So in C++ 23 we added something called is const val and then else and that is sort of like your macro and that gets evaluated program compile time itself and we can still preserve the conex code path and the non-conex code path which is an optical path [snorts] plans yeah we need to finish maybe get integrated with fuzz for continuous puzzing in uh we need to do better constant time guarantee. Right now we have some infrastructure setup but it needs to improve. Uh one of the things that I'm working on right now is a runtime um constraint time using valin and also for static time uh bin set formal verification. I'm not sure if that's possible because we use a lot of C++ 2020 new features. I don't know if any of the existing tools support those kind of things but the request explosive to be done. Uh we want to definitely run faster. when to reach as close as possible to the state-of-the-art implementation like MLK native, ML, MLGS native and um we we know how to do that thing AVX2 and the onest back end need to be added and uh maybe for rest five also uh we definitely want to include in the postpoint code package that'll be really good um and u yeah we want to keep adding very useful features but while staying as minimal and as lean as possible Yeah, that's all I had to say for the day. Thank you very much for listening to me.

[00:26:26]>> Thank you.

[00:26:28][applause] >> I think uh we have time for one question if anybody has a question.

[00:26:36]Um we have someone coming to the mic.

[00:26:39]>> So um thank you for your talk. My question is how do you think uh would doing these implementations in uh Rust change behavior because Rust also features many of the um um language features that you use for your implementation. So regarding um read code readability and maybe eventually efficiency but >> I cannot hear anything yet.

[00:27:08]>> I'm sorry. Could you repeat that on?

[00:27:14]>> Oh, he didn't hear.

[00:27:27]>> Yes, I can hear you now.

[00:27:30]>> Should I retry?

[00:27:32]Okay. Can you hear me?

[00:27:37]I can hear you but not very clearly.

[00:27:40]>> Okay. So I might step closer to the microphone. Sorry. Um so my question is how do you think um or do you do you think your findings would be replicated if you use instead Rust implementations instead of the modern C++ implementations as Rust by design features many uh of the features you use for your implementations. And um do you have ideas maybe how this would impact performance as well?

[00:28:13]>> Hart maybe can you repeat the question?

[00:28:15]I did not get it very clearly.

[00:28:17]>> Sure.

[00:28:19]>> Um I I I I don't know. I wasn't quite catching that.

[00:28:25]>> Yeah, I can hear you clearly.

[00:28:27]>> Yeah.

[00:28:28]The question is about rest performance.

[00:28:31]Is that correct?

[00:28:35]>> Yes, that was the question.

[00:28:37]>> Uh okay. Uh so like did I do a benchmark comparison against the Rust implementation? Uh is it a question?

[00:28:47]>> Yes.

[00:28:49]>> Uh okay. No no I I I did not do any uh benchmark comparison with Rust implement implementation. I know there is probably something from the Rascu and I think one is from Crispen uh if I'm saying it right. Uh so I think no I did not do any benchmark comparison yet.

[00:29:08]>> Okay. Thank you.

[00:29:11]>> Okay. Let's thank uh Anjen again. Thank you.

[00:29:15]>> Thank you very much. Bye-bye. Byebye. Um our next speaker is Jiun Joe from Samsung uh SDS where he's the vice president leading their integration of PQC algorithms uh as well as their cryptographic agility and inventorying for their systems.

[00:29:39]Please welcome uh Jun [applause] Can you hear me? Okay. Uh this is June uh from uh Samsung SDS. So um the title of my talk is um migration migration to PQC uh theory and practice.

[00:30:07]Um I got this title from this book because I uh first uh started studying cryptography with this book uh written by Stinson at Waterloo. Um uh I think um last few years I gave talk with title of cryptography at inflection point many times because uh I think um in a field uh in enterprise IT more than 15 years I see more like a diverse types of cryptography being deployed [clears throat] in the field and also quite recently um participating in the uh migration to PQC uh project by NIST.

[00:30:43]I also um uh think I think we have somehow reached uh where uh to reached the point where we need to change the way use managing cryptography in enterprise IT. So throughout the uh the talk I will focus on especially uh enterprise IT. It means uh we are we we provide uh IT services for many uh customers and then we run our own data center and also we are MSP manage manage the service provider my company. So we use the public cloud. So um we are a bit different from hyperscalers. So um um so I my focus I will focus on uh on my talk on that aspect. So of course I will talk about these two uh each topics um diverse types of crypto uh and also uh the way managing crypto in enterprise IT uh of course from the PQC perspective before that um migration to uh PQC is quite challenging at Samsung because as you see here we have uh more than uh 30 companies in many different uh sectors.

[00:31:52]Of course, uh Samsung electronics is manufacturing uh company and they uh also we need to uh protect its critical infrastructure uh with the cryptography but at the same time we need to deliver like a consumer product and also chipset very uh with a cryptographic uh uh implementations and also uh we do have finance sectors also IT service and then even we do have a Samsung medical center. So um my company again Samsung SDS provide IT services and infrastructure services to um all those companies also uh I I I we support uh customers in uh Korea especially public sectors and the defense sectors. So um throughout my talk I will uh I'm not going to all those details of of those technologies but I want to share uh my experience last uh or like a five or six years in uh PQC.

[00:32:53]So uh I I will talk about these two topics uh PC algorithms and design and also module uh implementation those uh modules and also uh the other topic is uh cryptographic agility which is relevant to uh actual actual uh engineering work uh migration to PQC.

[00:33:14]uh we we um u started to focus on a PQC uh algorithms like uh since 20 uh 22 quite late so we came up with uh we um signature scheme uh AMR is called AMR so it's customized version of a PN++ proof system and actually we uh uh implemented uh constructed oneway function uh is called AIM so uh and also uh we further uh uh improved it security. So we called it called we named AIM2. So AMR based on uh AIM2 is uh uh actually is a finalist the K pikushi competition. So in Korea we we've done some Korean Pikachu competition between uh since 2022. So u uh there was uh there were four uh finalist. So we are one of them. So basically three of them is two uh chem and two signature scheme schemes. So uh uh uh I think three of them is yeah three of them is from are lettuce based and um also we we've done some work for uh uh uh like make more efficient for this MPC database type schemes signature schemes and another ongoing work include ID based PQC because um uh working on in enterprise IT um for a long time I see more east west traffics is exploding. So it's all encrypted. So it's quite different. When I joined Samsung SDS 15 years ago, we didn't do encryption in east west traffic at all. But as you see like all those like uh uh big component of like enterprise applications divided into containers and they need to communicated in in uh encrypted trafficics and also um we also uh uh uh like they have to whenever they used like a call APIs like reach to from subject to uh some data resource or resource they need to uh they have to use the uh crypto keys. So I think um uh also we are seeing the physical AI these days. Uh we will see more like uh uh entities communicating in encrypted traffics um those entities where those entities owned and controlled by by a single entity single organization right so um ID based uh PQC maybe um good option for them. So um uh we are specifically working on bounded collision uh IB cam and also uh another important topic is interacting PQC with the higher level protocols. So we see many um uh effort uh integrating PQC uh with TLS and IPSC and others but we have so many other like security protocols and then um we are working uh on that uh uh scope and I think that this is one of those um uh uh scope of uh horizon project. So another also ongoing work is multiparty threshold schemes but actually um I'm theoretically I'm interested in uh this uh research but um uh I actually I don't know like it's really killer applications for multiparty threshold schemes. I'm really happy to discuss any of you you have a really good uh applications for uh multiparty threshold schemes. Of course, um we do I I I came across some uh solutions uh uh like um applying this uh previously uh uh threshold schemes for key management schemes like dividing those master keys into two like a one device like one the other keys in the cloud for instance but I don't really see um meaningful like a sk um uh meaningful uh applications for multi-party threshold schemes. I really want to find these applications.

[00:37:13]Uh another uh interesting uh topic for uh uh research is countermeasures against uh side channel attacks. So as you see like a uh diff uh this all types of like many types of uh PQC algorithms like they involve multiplications matrix multiplications and then those secret it is is being used. So um uh we uh we noticed um we can um find we can we can find uh uh those secret partial secret by um side channel text. So um interesting thing is we we of course we um uh issued uh we have many patent regarding this one but one of the patent won the Korean patent award because I want to point out this one because this patent award is open to all technology domains but last year uh we won the second place it means um the maybe I don't know the market value the PQC a lot more than I do I want to share that And also um we are very um uh we implemented a very different types of uh uh hybrid key exchange protocols um uh because uh we are talking about um harvest now and crypto later tech many times among this uh community but actually my experience is that um in in in in the field they don't care too much that much so I I told you like we uh support some uh Samsung medical centers and finance sectors. But they we know we um those uh some data need to be protected for a lifetime and then for instance in insurance as uh insurance uh sectors also uh medical uh sectors but actually the those CIOS CISOs that uh doesn't uh don't care that much because I it is a it is attacks actually taking like uh in the f very long in the future they think they think and also um they they do have a so many uh security breaches breaches these days. So they have a limited budget and that they want to spend their budget other like a more uh urgent security breach but um I I communicated with them like for a long time and then uh some trafficics like a free VPN traffic gateway gateway communications and also um I I just persuaded some very important uh traffics they had to be protected to be the hybrid uh this PQC uh enabled uh encrypted traffic traffic traffic. So um we implemented um uh uh many different types of hybrid key exchange um implementations in many different uh applications so far. So we used um uh many different uh standard and also we are working uh with the NIST uh in the with this uh uh this project. uh and also another point is that in Korea uh even though uh fifths uh fifths algorithms are announced uh uh we have a Korean CMVP program uh and then uh they don't really officially endorsed like in they they are not included in um Korean CMVP uh program yet but um they recently announced this uh last uh last early this year they announced uh this guideline um uh so they um they included uh uh the uh in in the case hive key exchange but they don't really they don't really specifically uh specify that like those uh detailed pack but uh they announced that they will hybrid key exchange will be uh part will be part of this um uh uh implementation so because we cannot purely um uh we cannot just deploy pure PQC only yet in Korea.

[00:41:18]Okay. Uh second topic is cryptographic agility. So we um we have many definitions about crypto agility but um I will um again focus on uh the cryptographic agility in enterprise it.

[00:41:35]So uh it is design feature. So also it enabling updates to other crypto modules without modifying or replacing IT infrastructure. Um so I I I gave uh two talks uh last year with um uh title of software defined cryptography you know this crypto agility workshop and those edg workshop because I I uh titled this uh my talk because cryptography became actually too complex to manage in enterprise IT and um it can be I think it can be addressed by software defined approaches because previously uh we have um uh network also had too many uh network devices and then uh they uh proposed this software defined network concept and then it uh this concept applied to like a software defined storage and data center and also in cyber security uh software defined the parameter and even uh further uh uh developed into general trust architecture. So um I will talk about this um the crypto agility I think um we have three capabilities for uh crypto agility in enterprise IT. The first governance, second one is automation and orchestration and the other last one is visibility and analytics. I will just go through one by one.

[00:43:01]So um I think it's getting more important. We need to um we need we need the centralized governance for cryptography in enterprise it because recently we had a really huge breach in Korea and then they failed managing cryptographic key materials. It was really huge data breach actually it is is ongoing uh uh event now uh and um because they failed to manage the cryptographic key materials. So uh um it's it's not really good option to uh let uh those developers like operating uh uh making uh those configurations and then also implement cryptographic uh uh uh uh configurations in the in the field. So we need somehow uh crypto center of excellence to ensure this cryp consistent cryptographic policy enforcement.

[00:43:55]Second uh capability is automation and orchestration. Uh but for this automation we need the abstraction. So we need to uh introduce abstraction for data plane in the like for encrypted traffic taking place. We need to separate it from the control plane and then we can automate. So I will give you some uh simple example. So still we use uh in enterprise it we use many Java applications and um thanks to it well uh architecture the modular architecture we can change uh the crypto uh providers without changing single uh applic uh Java applications. So um we whether assuming this pro provider one is does not support PQC and provider X support PQC. So by simply um updating this uh configuration file um you we we can just um um uh put this pro provider X supporting PQC on the on the top it's is a typo. So one two three one to three is a priority uh for the uh crypto providers like in the in the from the application point of view but um recently I'm uh engaging some encryption project in my company and then the thing is in enterprise IT u few engineers taking care of like maybe hundred or thousands applications maybe tens of thousands applications So it should be automated. So those jobs uh taking place um manually it it consumes a lot of time it takes a lot of time also um we it can cause errors. So it should be automated. So for instance uh we assuming some simple uh like uh IT services like dat storage and then uh web server was server and web server and uh like users uh uh uh interact with this web server uh via load balancer. So um this cryptographic policies can be nowadays defined as code. So um and also it is a common practice uh for the developers uh developers focus on application logic itself and then uh infrastructures and also all those configurations or including security uh can be defined as also code as well. So whenever this uh application is uh deployed, it can be deployed with the IA code together. And here um whenever this IA code is deployed um this um uh uh cryptographic policy can be also included in uh IA and then we can automate uh like a transition from u uh conventional uh cryptographic uh trafficics to uh PQC enabled traffic.

[00:46:52]So last capability is visibility. So the thing is um this is this is key baseline in migration effort because if we don't know which application use which cryptography we cannot we cannot automate we cannot do the migration right so this visibility is really important and then actually it is really difficult because again um we have so many applications also those applications use too many cryptography we cannot invent like we cannot um have a cryptographic inventory manually is is almost impossible. So we need to automate. So this cryptographic inventory is is asset is not only required required for fush piki migration but also it can it itself can be a cyber security asset because these days it is really important to have some uh all those like inventories like including hardware and software stacks in a sing uh central uh TV that we can manage each vulnerabilities. So this cryptographic uh um inventory can be generated for instance as a seabbomb cryptographic below material and then this seab can be imported into uh CMDB for instance central DB and then it can it can be managed uh uh centrally.

[00:48:10]So this also doing the uh project about this one. So um in enterprise IT we focused on enterprise IT in this project uh because it is difficult to gain because uh it volume is too big. So um uh but this can be done um automatically in a CI/CD pipeline. So we have a development pipeline also operational uh systems here. So um using automating some tools it can be uh the use of cryptography can be um uh uh uh can be found from the source code and the library [clears throat] and also files and also running systems on also from the network. But um we can we can find the use of uh uh the usage of cryptography from network by active scanning or passive scannings. But um when it comes to passive scanning this um this unfortunately uh in in [clears throat] you know security in security point of view is good like you know you know TS 1.3 all those handshake is like a more encrypted and then so actually you know uh cryptographic inventoring uh point of view is more difficult to detect.

[00:49:25]So uh this um one of those uh uh uh uh like um example of cryptography inventorying is we usually in enterprise it we we use the Jenkins this is a CID uh orchestration tool. So this uh agent uh like this uh uh inventorying agent can be plugged into Jenkins and then we can find those cryptographic uses from uh this um uh in this way.

[00:49:58]So um yeah uh this this is last one. So um I see uh this cryptographic migration somebody already mentioned it takes maybe more than 10 years 10 to 20 years but it should be um as as I mentioned it should be automated. So um with that purpose like um uh my as I as I uh discussed network and it fra was so complex getting complex and they were software defined and then security became also very complex uh to manage it. So it was software defined. So now I think crypto also must be software defined to especially um at the point of mig migration to uh PQC.

[00:50:42]Thank you.

[00:50:46][applause] Are there any questions for Jun?

[00:50:54]I don't I don't see any but I have one.

[00:50:56]Um I'm wondering in your policy as code aspect in your build pipeline like have you do you have any lessons learned that you've used that on in particular some crypto configurations that are going into the build process today and things that worked well and things that didn't.

[00:51:15]uh for for uh for that one we uh we haven't done a pilot yet just we done a PC internally and then maybe those lessons will be found later on in a pilot or like actual implementations but these days um in Korea we um uh we I just we select the inventorying first so uh we try to uh uh plug in plug in uh integrate those uh inventorying tool into CD pipeline We just uh Yeah, we just started from last year. Yeah.

[00:51:52]>> Um any other questions?

[00:51:56]>> Oh, hi Thank you. Yeah, he's learning Korean, so he will ask a question like Yeah.

[00:52:22]later on.

[00:52:26]>> Sure.

[00:52:28]>> English, not Korean.

[00:52:30]I'm I'm from Korea but uh I'm very interested your talks will of course using the software defined cryptography it is very wonderful idea we are using the SDN software defined network and there are many practical application the software basis so far we are using the hardware basis approach so you are now moving to the from hardware to the software 4G. On the other hand, we have to concern the another point of EP approach software you know that uh we have to check not only the crypto security but also we have to check the performance and the safety and AI based attack and blah blah blah lots of works to we have to consider together so that uh in in concern of the AI based AI point of view the software is quite vulnerable to the abuse relatively compared to hardware. I this is my understanding. So you are considering any the the counter measure of use of if you apply the software based approach that is my question in in English not Korean >> okay uh actually it is named the software defined approaches but it actually doesn't use the software actually this software defined approach is like a concept to managing to uh like many entities in a data plane so it can be hardware or it can be software there.

[00:54:11]So um uh that's my question that's my my my answer. So uh yeah so we definitely using this software defined approach we can of course in implement like uh entities using cryptoyapy in hardware of course we can do that.

[00:54:28]>> Thank you for your talk. I was curious to know which what types of challenges and roadblocks you ran into in the inventorying process and to what extent you relied on previous uh crypto inventories or a cyber security related inventories.

[00:54:45]>> Uh if I uh uh uh understand your questions, what is the challenges for crypto inventory uh process?

[00:54:53]>> Yes, >> correct.

[00:54:54]>> Oh yes.

[00:54:56]Um most difficult uh difficult part for crypto inventory is like um make them do it because um um in Korea like um uh many like as I understand like uh federal agent in USA they already started like a migration but Korea uh actual full full scale migration will begin uh 20 since uh 2029.

[00:55:22]So as I as I told you again they have a too CISO these days they have too many like um event and issues to to consider.

[00:55:31]So um they don't really interesting like in um push migration that much and another point is it's too difficult to them to understand because uh this understand this concept of quantum computings and based attacks and then PQC and the like difference between QKD and PQC. So um my my experience is the like experience is the uh persuade they make them understand uh those uh what kind of like a job they need to do like uh also I always try to uh uh persuade like they have to first uh planning first like uh so uh is long-term process right so um that's my actually it's not technical one it's a very um kind of like a management aspect is very difficult Okay. Uh let's thank Jiun again. Thank you. [applause] Our next speaker is Thomas Oban who's uh at Google's um information security engineering division where uh he focuses on the development of their cryptographic libraries. So please welcome Thomas.

[00:56:44][applause] Yeah, thanks a lot for the invitation and uh the opportunity to speak at uh Ruber PQC and uh this talk is a bit also about a personal journey. Um I worked for a long time in hardware. Um I was 10 years at Infinion working on secure microcontrollers and smart cards. Before that I did a PhD in let us brace cryptography contributed also a bit to the PQC competition of NIST and yeah now I'm a software engineering manager at Google working on cryptographic libraries so members of my team are contributing to open-source crypto libraries like uh tink and boring SSL and um yeah I thought it might be interesting to showcase a bit the different themes about the PQC migrations you may find in silicon and also in the cloud world and uh because I'm now a manager there will be zero math in this presentation um just very high level themes and uh a lot is also personal experience um not probably not even real research and uh your experience may vary and I would encourage you to use the Q&A uh to share to disagree or to agree. Um now a quick definition. Um yeah, as said the goal is to bridge a bit the gap between the silicon and the cloud community, find common themes, initiate the discussion.

[00:58:24]Um the definition of silicon on these slides is an embedded chip that has a few megabytes of software. So something that you would usually find at chess. um something that could be a contactless uh payment card you use at at a terminal, car opening, embedded chip cards and so forth. And I think a few years ago, you would also need to distinguish between secure elements, so chips that really target an environment where physical attacks can happen and just general purpose microcontrollers that don't have any claims about physical attacks. But this is also changing rapidly. So with um the um um platform security architecture um PSA and the various levels there even standard microcontrollers nowadays have features that prevent physical attacks and the the distinguishing or it becomes much harder to distinguish between smart card secure elements and MCUs. But in general silicon here means things you would find at chess. Um and then for cloud uh cloud also runs on silicon. I think that's quite clear but uh the silicon is not the most important thing in the cloud. You have a lot of complex software um with a lot of different constraints and uh yeah these topics you would usually hear about at real world crypto. You're trying to secure users at scale. You're doing this in a yeah in a worldwide fashion. Um and uh yeah both worlds are different. Let's see what PQC means for them. So if you look at silicon then at least the use case is often quite clear because when you start a silicon development you have to determine what the chip should be used for. Of course users might be creative but usually if you're not designing a chip for a use case that doesn't make any sense. So you can also somehow figure out what schemes do you have, where will the chip be used, what performance do you need. However, when we're dealing with PQC on silicon, then we're really counting every cycle and every bite. And especially PQC puts a lot of burden on a lot of these embedded devices. So when implementing the library, you're really spending a lot of time with the debugger low level squeezing out every everything. And especially on devices with only a few kil few kilobytes of RAM, you cannot simply copy keys and have three or four copies of these keys in a in the device because you simply ran out of memory.

[01:01:10]Um, usually in silicon you deal with product cycles of years, which has been particularly interesting for the PQC migration because some of these chips probably have been chips you see today have been designed prior to the end of the NIS competition.

[01:01:29]Um, usually it takes years because you first have to define the silicon, you have to design it, you have to um manufacture it. Even this can take a few months. Then the chip comes back. It has to be validated. Bugs have to be fixed.

[01:01:43]Updates have to be made. Mass production needs to be started. And we can even see that if you have invested too early into PQC, then you may have increased the product cost. And this is also something that you don't see in the cloud environment. If you have added five years ago hardware, for example, for psych, this hardware is now a waste and nobody will pay anything for this hardware. If you have added even maybe lettuce hardware for a long time, this chip may have been in the market where nobody wanted to pay for that. And this is really the challenge in in silicon that additional features are not just costing you engineering time and opportunity cost, but they may also just make the product more expensive. And even though the the cost of PQC may be small, it still eats into the business case.

[01:02:37]And then what we also see is of course even though a device may be updatable, you're still constrained by the available NVM and RAM. Yeah, you cannot simply roll out new crypto if you don't have the NVM and the RAM. And again, if you're targeting costsensitive markets, usually you aim to use all of the NVM and RAM that is available. Um plus uh updates are also constrained by the update of the ecosystem and available engineering resources.

[01:03:10]And then if you physically secure PQC against side channel attack faults fault attacks this will affect the whole chip and usually this is something that you cannot simply do in isolation and uh I will go into this also a bit later.

[01:03:27]uh now looking at cloud I think in the cloud [clears throat] environment the problem is different. So we have a massive ecosystem we have a lot of scale and by this simply we have a lot of complexity.

[01:03:42]I would argue implementing the PQ algorithms itself this is the easy part.

[01:03:47]Um this is usually also the fun part. um this is what engineers want to do but uh in reality I think they spend much more time on other things than just implementing the base algorithm. So let's hope that uh AI will not get too good at this so that it will not take away the fun part um and we are just left um to figure out dependencies.

[01:04:12]Um the good thing in cloud is you have product cycles of days and this allows you to experiment.

[01:04:20]You can also invest too early into PQC.

[01:04:23]It's just an opportunity cost. It usually doesn't make the product too expensive. There are a few cases of course with latency, larger key sizes that can cause problems, but in general in this environment, you can roll out a PQC experiment and you can roll it back. And uh you're usually only or mostly constrained by what the ecosystem can do, especially if you have communication endpoints. Are they compatible with your experiments or with PQC and the engineering resources? And then there's one thing in cloud that really matters at scale and this is API ergonomics. Um the APIs of a lot of embedded software are probably pretty horrible but only few people use this. Um while in cloud a lot of products require PQC and security and uh the programmers that are working or building these products products they are usually not experts in using them correctly. So I think this is something that is has a much bigger focus in in cloud than in the silicon or embedded space.

[01:05:35]And uh yeah, what does this mean? Um, it could be that even if new chips enter the market today, they may still struggle with PQC because they may have been designed in a time where it was not really clear which algorithm will win.

[01:05:50]Um, or if you can even earn money with additional PQC features.

[01:05:56]I would argue in the cloud the the task of migration is quite clear. Well, we have to do it. We know what to do. but just does this immensely big scope.

[01:06:07]There are so many products that use cryptography and uh figuring out all the tiny issues, incompatibilities, this just requires a lot of work. So I would argue um in silicon you're often uh stuck making it work and in the cloud um the theme is more making it safe to use at scale.

[01:06:30]And then also in silicon and cloud I think you have two different nemesis.

[01:06:36]And um when talking to people who who are working mostly in silicon and in cloud it's often you or at least be during the NIS competition you see themes like we need we need signatures first or we need cams immediately and this is also due to the different focus.

[01:06:54]So if you look at at the silicon I think the biggest risk is the large scale compromise of firmware and this is why you need firmware signing and you need a postquantum protected uh field update and uh secure boot mechanism and um there the the big long-term risk is that the devices with an outdated root of trust remain in the field basically forever and it's very hard to replace these devices. So I think the focus in silicon for products to go to PQC the first step is really to fix field update and firmware signing and to put a lot of effort into this. Um the nasty aspect is if you use PQC during the boot process it affects the boot time and this is in a very important KPI in in VMware and it may even double or whatever the the boot process. Um in cloud we see a different theme. In cloud we have this act now even though it may already be too late because uh harvest now decrypt data attacks they affect billions of users and in the cloud environment a lot more yeah privacy relevant personal information is transmitted. Most of the silicon or embedded devices mostly deal with authentication um or this firmware signing topic. Um and then yeah we have this risk of data inception and storage in cloud. Um where where's [snorts] affect where's cloud affected by firmware signing? So silicon devices are also used in data centers and if they have outdated root of trust they need to be replaced. this can be expensive. And at the same time, we also see more and more um HAI products or very yeah powerful embedded microcontrollers that transmit biometric information or other things that also need to be protected against harvest now decrypt later.

[01:09:02]Now looking at libraries a bit more in detail.

[01:09:06]Um we can also see this theme of making it work in silicon um and the complexity of getting the basic algorithms to run versus the scale in the cloud. So when looking at crypto libraries that usually run on an embedded device, we are still following the V model. Yeah, we are still defining requirements and architecture detailed design. Then the coding is happening and this is accompanied by unit testing, integration testing and system testing and this takes a long time and it has to be done in sync with the hardware. So a PQC cryptographic library on silicon depends not just on the CPU. It depends on all the available hardware accelerators and it depends on the security concept and usually you have different versions of all of these because you may fix a bug in your sec security concept, you may fix a bug in a hardware accelerator and you may upgrade your CPU and then the cryptographic library that is running on these silicon devices has to work through a broad range of products with all these different versions. It has to go through a complex certification especially if physical protection is involved. So you have common criteria um can be a six-month process and if you find something you enter the v modelel again update uh the architecture design code testing and go through the process again um and you have also things like fips what you also have to do in silicon if you want to make pqc work is a lot of so-called secure coding so you may have to add manual redundancy against fault attacks simple example example is an if statement. Maybe you want two or three of these if statements in order to prevent an attacker from being able to jump over this via fault attack. This is usually a manual step you do in the code. And if you introduce secret sharing then yeah you have to rewrite your whole library in a way that uh no information about the secrets is leaked using masking and other techniques. Um the good thing of course in silicon is everything is mostly C. Um I think there are some experiments with rust but in reality everything is still C. Legacy stays forever. What's there will never get replaced and uh which also means if you if you do PQC migration you want to get it right. If you iterate, I think it will be very expensive because all these intermediate steps will have to be supported forever and you will probably end up with the library with a lot of ifdeaf statements um that you don't want done on. Um and then you also put new crypto so PQC is fairly new into readonly memory and this is sometimes a bit scary because there's no way to update it unless you do a new tape out and build a new product. So there may also be a bit of fear should we really move to PQC because it's it's so new it's so fresh will we really get it right. Um I think cloud in this sense works different because the complexity as I've said is not in the base algorithms but usually in the complexity of the call stacks you have a lot of independently moving parts. So while in silicon you try to constrain change um you don't want parts to move in the cloud usually you want to be up to date you things are moving you will anyways not stop them from moving and um so this is just the example for the call stack of Google's tink library very simplified but you have the tink library and you have to support this library in multiple languages so Java Python C++ plus and even more. And then you use low-level crypto provider. The Java implementation may use the Java cryptographic architecture. It may use um conscript as a middleware and then call boring SSL. The C++ implementation may use open SSL, but it may also use boring SSL. And all of these different uh crypto components, they also have direct users. So they may also get requests can you add this feature here? Can you update this? We need to fix this API. So I think here the challenge when yeah transitioning to PQC and of course in general is to keep all these moving parts together.

[01:13:41]And then of course PQC requires multi- language support. So at least you have the ability to implement PQC in a lot of languages if you like to implement the base algorithm and most likely and new languages are are also invented. So this gives us something to do. Um but at the same time of course we have to make sure that all all these multi- language versions that they are compatible and that they still fulfill some of the certifications like FIPS and FETM. Um all these libraries are used by a much wider community. So there's a higher risk of of error on the user side. I mentioned this already. We need safe APIs. And then I think it's a big advantage for the migration if you're living at head which is a concept that for example Google has with the monor repo that all the products are using the latest version.

[01:14:32]There's not this very nasty version tree that you would usually expect to have in silicon. Um, this allows you to eventually remove legacy code and to deploy PQC much faster.

[01:14:47]So, themes for PQC transition in silicon, there's a high initial v high initial investment for the vendor to just get the basic PQC libraries.

[01:14:58]There's a very high penalty for change.

[01:15:00]You want to get it right on the first um attempt.

[01:15:03]um for the cloud or the software ecosystems in general. It's much easier to start with PQC. Um but the ecosystem is very complex and you still have to deal with a lot of legacy code and tech depth.

[01:15:18]Um now the question is why why is PQC now hard in silicon? And I would argue it's not RSA and ECC. Um because if you look at RSA ECC, it's actually not so complicated to do this in a chip. Um because you can scale performance quite easily. What you need for RSA ECC is you need a fast multiplier and you need a memory and then you hook the multiplier to the memory and make sure that the memory bandwidth is good enough. select uh the algorithm of choice for scala multiplication and then you have a simple RSA ECC accelerator and for the multiplier you can do this very low level or you can let the synthesis tool decide which multiplier to use and then you can really scale performance with one implementation quite nicely.

[01:16:10]Um this can be done also independent of the system. You build the multiplier, you attach it to the system bus, you interact with it, but the data is quite small. Um, and security is well understood. We even have things like blinding, projective coordinates. We have really nice math. Yeah, we have math that is nice end to end and that allows us to build also secure implement implementations quite efficiently. Um and in PQC I would argue the challenge of migrating to PQC in ch in in silicon is really the system because uh if you look at MLAM MLDDSA you have so many diverse building blocks. You have you probably if you would build something in hardware that is still flexible. You would probably want a SH3 engine. You want something that does bit operations.

[01:17:01]You want something that does polomial multiplication. So an entity accelerator or something like that. and you need a lot of memory and the system that has all of this already is called the CPU subsystem. Yeah, in the CPU subsystem you have already memory, you have bit operations and you even have in the CPU often vector instructions that are quite good at uh yeah computing polomial multiplication. So if the if the performance of the CPU subsystem is not enough, you have to spend a lot of effort and me you have to spend a lot of hardware area to go beyond that and by accident you may build a new CPU subsystem. So why not simply use the more powerful CPU subsystem. Um so here scaling performance meet means you have to balance all the different functions.

[01:17:51]You cannot just invest into a fast sh 3 because then the other stuff is too slow. Um, and if you've made all of these components really fast, then you will notice that your system bus is too slow and that you're not able to move the data from A to B. Um, so you need to wire up all these blocks probably in some proprietary fashion to make data movement fast and uh in general you have to deal with long data structures. So polomials in lettuce based crypto are quite big and the entity is super fast.

[01:18:20]So if you build a hardware implementation, you're dealing really or you have to be much more careful how you move data in the system.

[01:18:32]And then of course if you do a secure implementation, for example, a mast implementation, you have a lot of these conversions between arithmetic and boolean domain, which is expensive. And if you want to do something that's protected against fault attacks, I think for now double calculation is the only thing we have.

[01:18:50]So there's no really nice math in PQC.

[01:18:54]Um at least no math end to end.

[01:18:59]Um and then we also have the hybrid tax.

[01:19:02]Um I think this is quite clear. The next decade will probably hybrid ECC plus PQC. Um with PQC we are not sm swapping.

[01:19:10]We are just adding new algorithms.

[01:19:12]And uh in silicon often the crypto timer budget is not or the goal is not to be as fast as possible because nobody is willing to pay for that. No customer wants to wants to pay for an overengineered product. But the crypto time and budget is use case bound. And for example here if you do a payment operation you want to take your card you want it put it on the reader it should make beep within a very short time frame and that's good enough. And most of the chips that you see today, they are designed exactly for this good enough use case. You put the card, it makes beep, transaction done. But uh if we now add PQC into the mix and we want to do hybrid, we have a problem because even super fast PQC will not be a help because we need to make some room in this already squeezed out use case. So it could mean that uh yeah you have to redesign your ECC hardware for PQC to make some space uh in the protocol to enable hybrid and um yeah this is a challenge. Um in cloud I think we usually pay just with latency and cost.

[01:20:22]Yeah, we're adding more latency um because of the size and of course we also have to keep maintaining the ECC implementations and uh yeah the last thing is stateful and clown don't go well together. Um, if you're coming from a silicon background, it doesn't sound so scary to do XMSS or LMS even on a product because on a silicon device you already have nonvolitile memory, you have counters, you have physical uniqueness and you also deal with the text that try to bring you into a different state and managing state safely is somehow a core competence of secure silicon. So if you talk to silicon engineers, maybe they would be open to the to the temptation to implement XMSS LMS on a product while at the same time in the cloud you don't want to do that. Yeah, there's an absolute no because if you snapshot or clone a VM it instantly breaks security and there's no way you can manage the state really in a safe manner.

[01:21:26]So inclusen PQC is challenging in silicon and cloud in their own ways. Um on the other hand it seems to be quite clear what needs to be done. Uh we have to do it. Um and uh yeah I would also like to hear maybe if you have different views on on the material I just presented and uh yeah enter a discussion. Thank you.

[01:21:52]>> Thank you. [applause] Uh, are there any questions?

[01:22:10]>> So, after the transition to ECC and PQC, would that be then going to just PQC or is there an advantage to having both?

[01:22:22]That's uh I mean we all don't have a crystal ball.

[01:22:27]Um of course you can imagine a scenario if we move to hybrid and PQC stays secure and we don't see any problems in the next 10 years that we gradually phase out ECC.

[01:22:40]If something happens to the PQC algorithms probably we are stuck with ECC. And then in products that we can't update or where we have legacy systems, we'll probably still have PQC in 30, 40, 50 years or whatever. Similar to I think MD5 is still around somewhere. Yeah.

[01:22:59]Thank you.

[01:23:04]>> Question perhaps somewhat of a comment more than a question. uh you were talking about uh hardware vendors and state um rumors I hear are that for the HSM vendors don't want to do stateful either they say too hard it's a software problem that the software guys deal with it that's also a problem of course if you're building a product and I think it yeah it's hard yeah and and um depends also on the architecture of the HSM which could be more not so embedded if it's for high performance applications. But this is also a challenge if you build uh if you build a chip where you want to use stateful hashbased signatures for verification, you need to find a good HSM vendor that uh supports this. I have no good overview of the market, but that's also a challenge definitely.

[01:24:10]So not only silicon and crowd but also we should also consider the development of quantum computer and we know Google is also developing quantum computer. My question is when will Google move on PQC >> can you maybe also Google is also developing quantum computer.

[01:24:32]>> Yes. and not only silicon and proud we should also consider development of quantum computer uh when we need to move on PQC we need to also consider development of quantum computer maybe we can take that offline because I'm I'm not sure if I understood the question sorry uh any other questions Okay, let's thank our speaker again.

[01:25:06]Thank you.