Session Date/Time: 22 Jul 2026 07:00
[00:01:15] Alexey Melnikov: Okay. So, actually, we should start. Yep. Alright.
[00:01:24] Nick Sullivan: Can drive some of the slides during the presentations if you want to.
[00:01:27] Alexey Melnikov: No. It's fine. Okay. I think it's just easier. And now I don't need clicker because I can just press next itself.
[00:01:37] Nick Sullivan: And this thing is connected to
[00:01:40] Stanislav Smyshlyaev: It it works. It was tested.
[00:01:48] Alexey Melnikov: Today is Wednesday. Good good morning. Welcome to CFRG session, first of the two CFRG sessions on Wednesday at Vienna ATF. Let's get started. So I'm I'm Alexey Melnikov. Nick Sullivan is sitting next to me, and Stanislav is remote.
[00:02:12] Stanislav Smyshlyaev: Hi, everyone.
[00:02:20] Alexey Melnikov: Okay. Just to I think do we have a note before we do automated document? So as usual, this session is being recorded and will be posted on YouTube. And people are reminded of the participant code. Please note. Right. Sorry. Note well about intellectual property. I hope people are familiar with this. But by participating in the session and coming to the mic and on the mailing list, are subscribing to IRTF rules. So as I said, the audio and video recording is being made and will be posted. And also remind about code of conduct. So we have agenda. We have some bashing of the agenda because, actually, there are some conflicts with other sessions we didn't anticipate. So is Chris here? Yeah. I think
[00:03:52] Nick Sullivan: so. So the suggestion is that Christopher Wood and Abhi Shelat move up their presentations to nine nine forty over the open discussion. Any any objections? No. Okay. So we'll continue in this order except for the hybrid post quantum peak and Longfellow will be first after the open discussion.
[00:04:23] Alexey Melnikov: Yes.
[00:04:25] Stanislav Smyshlyaev: K.
[00:04:30] Nick Sullivan: Abhi first.
[00:04:33] Stanislav Smyshlyaev: Just to clarify, Abhi will go first and then Chris Wood will be second after that.
[00:04:44] Alexey Melnikov: So as a reminder, we are in IRTF. So our primary goal is research. We don't we don't publish standards document.
[00:04:57] Nick Sullivan: K.
[00:05:03] Alexey Melnikov: We have a adjacent entity or additional group called Crypto Review Panel that was formed in 2016, which is used for reviewing documents for CFRG, for security area, for independent stream. The goal is to provide critical objective timing, consistent reviews. We frequently invoke them, you know, just before c o four g last call, for example. The membership just got review renewed. We have a new panel. Some members are continuing. We have some a lot of new people. So this is the current membership. And this panel will be for two years. Okay. And now very quick status of various documents. We don't have new RFCs. We have one document in RFC editor's queue. RSA guidance in ISG review. We have CPASE in IRSG review. Nothing is waiting for the IRTF chair at the moment. And we have set several documents in IRTF last call. In research group last call.
[00:06:44] Emil Nygren: Yes.
[00:06:47] Alexey Melnikov: Some of these are completed, and we kind of need to follow-up and close them. But
[00:06:57] Stanislav Smyshlyaev: okay.
[00:07:01] Alexey Melnikov: No document in the crypto review panel at the moment. No new adopted drafts. This is a list of active drafts. If people spot any errors or typos, please let us know. Or if you think the status is If you are one of the editors and you think status is inaccurate, please let us know.
[00:07:39] Nick Sullivan: So there are three errandas reported since the last meeting. The tools team is updating and has fixed our ability to put these together. Here are the proposed resolutions for these three. If you have any opinions, please share them with the chairs so we can move on.
[00:08:02] Alexey Melnikov: And with this, you want Okay.
[00:08:14] Nick Sullivan: So one of the ongoing conversations on the list is about the PQ Chem security considerations. There were a a lot of really well written drafts covering various aspects of using PQChem securely targeted at a good list of them that have had a lot of public external review, including the ones here. This is sort of a lot of documents. There there has been expressed in interest as to having security considerations that can be referenced from the CFRG for other pro for other protocols and other working groups such that when they're in last call, they can, for example, refer to these instead of answering the same questions a thousand times over, among other things. So we've received these inputs. We've opened up the mailing list conversation. There's been a a few a few back and forths on it. And because this topic is still of interest to many working groups and the shape of what the adoption of the topic of PQChem security considerations isn't clear yet for the chairs, we are opening up this time for any public comments, questions, ideas. So the in particular, there's three questions that we would like comments on, And these were suggested by folks on the mailing list in during this discussion and debated one way or the other. The first is, is there use for a one common chem use guidance document that applies across all chems and chem shapes that sort of factors out some of the shared considerations that fit into all of these particular ones? That's the first question. And if so, does that imply that if somebody want to write this common guidance integration, and then we would we also adopt these per chem analyses or just a simple common document? And then after that is if folks have reviewed these documents, do they match a fit for purpose criteria? And does anybody have a proposed beyond what was proposed by the chairs, set of criteria and recommendations for what these documents should end up looking like should they be adopted and moved through the RG. So this call is pretty broad today. We wanna hear all public input before we decide what shape the adoption call is. And with that, we open it to questions or comments from the group. Even if it's we don't want security considerations, that's also a valid comment. Okay. So we've got two people in the queue.
[00:11:33] John Preuß Mattsson: Yeah. John, there seems to be quite a lot of people wanting to use FrodeChem. And, I have I hearing a lot in other ITF groups, there seems to be expectation that CFRD would publish this FrodoChem so that the ITF working groups and now they can refer to it. I think that would be a good idea. I think you should. But I heard from the chairs that you don't really want to do that, at least not now. What what would be be the approach? I don't think any ITF group should refer to Paywall crypto. So if you don't publish FrodoChem, the ITF working group need to find some other option. Is that ISE, or we'll see if RG have an adoption call for FrodoChem soon.
[00:12:27] Nick Sullivan: So the question is, why don't we republish other documents? This is a research group, not a republishing venue. I don't know. Republishing ChaCha twenty, I don't really see much of a difference. Sure. I mean, some of the examples that we've had in the past have gone through and been reviewed in other standardization venues. And the sort of topic of the way that the the problem statement is is shaped is was around the demands and the requirements of the the TLS and other working groups who were asking for alternative AES GCM alternatives to AES GCM that were fast and software. So that that was a problem statement for which ChaChaPoly and then subsequently Aegis, which is in the in the last call, were brought to CFRG. With respect to Frotochem, the the security considerations could potentially motivate it because at this point, the chairs have feedback like the ones that you're that you're giving that somebody wants to reference a document. That's not a problem per se to solve within the CFRG. That's there's no research question there. There's no like, we have a particular set of constraints that are non policy based that would drive us to use that for up for us to look at. So all of these other sort of specifications that we've specified are intended to solve problems for the ITF and and others that are well spelled out. And over the last few years, we've kind of clarified the CFRG process as being a venue where security engineers, protocol designers, and others can come here with problems to solve. And if there's a well stated problem that FrodoChem solves that, say, NLChem doesn't, that is is something to bring to the table. But we've, over the last year or so, reviewed these sort of things. And the shape of the the question that we've gotten is, is it safe to use these? Or what are the parameters in which it's safe to use these particular aspects? From the chair's determination, that's the best sort of input that we can provide from the CFRG is not in particular rerunning a contest or competition. This has been done extensively in other venues, and, you know, we we did that for PAGS because it hadn't been done extensively in other other venues. So we're hoping for feedback as to, like, if folks want to adopt Frotochem within their protocol, they're fair and fine to do so. And with if they don't have the expertise with regard to analyzing the security considerations, what sort of issues would come about when implementing this, there's nothing for them to refer to, and they have to do that sort of work in a working group. So that's the general motivation for this PQChem considerations work. So I don't want to speak for other groups, but there was at least one working group that wanted to do ProtoChem. And we're not waiting for a specification, but we're waiting for some sort of validation that it's something that is safe and secure to use within the ITF context. And this is what this set of of security considerations works is is intended to do is to enable other groups within the IETF to be confident in their use of, say, these different chems if they choose to, not to provide a full throated endorsement of, you know, any one over the other, but to to allow work working groups to be a lot more confident in making their cryptographic choices, which is, I think, a pervasive issue within the ITF.
[00:17:02] Scott Fluhrer: Hi. Roman May.
[00:17:06] Dan Harkins: So we've got a lot of RGA items on our plate. So this is kinda like, you know, somebody said, hey. Would you like a car? Like, oh, that sounds nice. That's like, well, what do I have to give up to get it? So my next question is, are do you have people who volunteered to go and do this work or that you think are are available to go do this work that wouldn't be pulled off of some of the stuff we already have? It's a
[00:17:40] Nick Sullivan: good question. And I I think the feedback that we've gotten from this from the last ITF is in the form of many full documents from folks who haven't even participated in the CFRG before, who are willing to get involved in the IETF and standardization. And we welcome that, and we welcome growing the tent. And in terms of taking away from other other groups, The the intersection with existing working documents in these is is actually very small in terms of the author list.
[00:18:15] Scott Fluhrer: Scott. Scott Flores, Cisco Cisco Cisco Systems. I see this as important work. I'll be honest, more important than most of what's happens to CFRG because it's a k most of the work is niche issues, which are in of interest of maybe a couple protocols. Almost every protocol security protocol uses m some sort of chem in some way. This is more general use, and they need and various working groups need guidance. As for the questions, I don't see how a single document possibly cover all chems, including chems in the future. There may there are some common criteria like good randomness, please, which is applies to everyone. On the other hand, I believe that there are questions, especially in the odd cases of you using Canvas authentication, where there are subtle differences which need to be pointed out. Thank you.
[00:19:18] Nick Sullivan: Thanks, Scott. And to that point, several of these documents explore beyond just the specified chem and explore some of the mathematics behind it that may be shared with or maybe potentially used in the next round of chem standardization, for example. So that's something to to maybe keep in mind here is that if these inputs would not necessarily be targeted exactly towards the versions of these documents that have gone through other standardization specific processes, but could apply more general generally to say the hard mathematical mathematical problem behind it that would be reused in or could be reused in in future specs. So the hope is that these would be somewhat generally applicable as well as directly applicable to the ones that the ITF is is considering today. Tanya?
[00:20:24] Tanja Lange: Yeah. Trying to get the camera working. Hi. I think it's useful work, and I really like the the, well, interest in the community getting lots of more people involved. I mean, having more cryptographers on here is certainly helpful, and maybe we can slowly direct them to also contribute to other things. I think security considerations are very valuable. I think it's also useful to have usability considerations. I mean, knows that class MacLease has two large keys, but not everybody knows that it has very small ciphertexts, which can be useful if you have something like TLS chem, where you have a static authentication key and you're really benefiting from the small ciphertexts. And so, I mean, for this call, of course, people highlight the security considerations, but I think it could also be useful to have practicality consideration or usability considerations. And there, I see more need for comparison. I hear you, Scott, that sometimes one can't compare things because everybody feels like their cipher is particularly secure. But I think for sizes or for speeds, these are more easily measurable things where one can have tables comparing across different camps. And I think that would also be a valuable thing, but wasn't requested in this round.
[00:21:46] Nick Sullivan: That's certainly valid feedback. The usability within protocols of of each of these, the in in terms of size and whatnot, I think, is something that should be mentioned at the very least.
[00:22:01] Russ Housley: As a veteran of the hybrid wars, I just want to incur I think this would be really useful. I see it as, like, you know, how do I
[00:22:10] Emil Nygren: say it? You go to
[00:22:12] Russ Housley: the bookstore and some working group finds, oh, so you want to exchange keys. And it you know, it's things to look at because people have a problem to solve when they're not as familiar with all the trade offs they'll have to make. I think enumerating those kinds of trade offs and thinking, well, consider this, and some do this, that's really worthwhile. But be very careful about doing something, at least in the base document, that leans towards favoring one thing or the other because all of the other sides will come out of the woodwork and swarm over this group.
[00:22:44] Nick Sullivan: So this is about for having one one central document that is focused on potentially just the the very high level things that are are different?
[00:22:57] Russ Housley: I I agree. Yes. I think, basically, yes. I think there's enough common issues that people need to consider that they're not aware that they need to think about. Like Tanya mentioned, key size versus the result in, you know, encrypted size. So yes.
[00:23:15] Tanja Lange: Hi. I got myself in the queue again after your feedback, Nick. So I was not just trying to give this as feedback, but I was trying to make a plea for an additional document where I mean, it would be nice to have a call for peak volunteers to do this because I think it would be very useful to have a document that does this comparison. Additionally, I also would like to put my support behind, yeah, CFRG publishing some security considerations.
[00:23:40] John Preuß Mattsson: So will
[00:23:40] Tanja Lange: actually not just feedback, but, like, hey. Request for action items.
[00:23:46] Nick Sullivan: Great. Yeah. Thank you. And and that does echo one of the questions I asked at the beginning here is we have authors for all of the specific documents, but we don't have volunteers per se for a shared shared document if we were to go in that direction. So if there's interest in is that a potentially contentious document like this, somebody authoring that, we we would love to hear it.
[00:24:17] John Gray: Hi. It's John Gray from nTrust. I was just gonna say, yeah, this is valuable work. Actually, it would be nice if it was already done because we're actually implementing this stuff now. Right? So the practical considerations, you know, guidance for engineers. Like, you know, I I tell, you know, our teams at our work that, you know, there's not just gonna be MLChem. You're not just gonna it's not a one and done. There's new things coming, you know, and having something that describes those differences or the commonalities. And then, you know, maybe other documents with the differences will be really helpful and, you know, describing the shape because chem is a completely different animal than, you know, what we've been used to for the last twenty five years. So this is really good. And I yeah. I'd like to help out with it as well. Thanks.
[00:24:58] Nick Sullivan: Thanks, John.
[00:24:59] Stanislav Smyshlyaev: Okay.
[00:25:00] Scott Fluhrer: Scott Fluor, Cisco Systems again. One of the things that I'd like to highlight is to remember who the audience is. Nick mentioned that maybe we want to dig into the mathematics in the chems. I believe that is a side issue which should be avoided because this we are writing it for working non cryptographical working groups, and we need to keep it relevant to them.
[00:25:27] Nick Sullivan: Thank you. Good feedback. So we can register that as you can list the hard problems, but don't explore them.
[00:25:38] Christopher Wood: Victor?
[00:25:41] Victor Duchovni: One thing I hope is relevant.
[00:25:44] Thom Wiggers: We have a bit of
[00:25:45] Victor Duchovni: a mess brewing in terms of the key formats for hybrids between HPKE, which has a master seed that derives the underlying seeds for the two components versus what's going on in lamps where the specification seem to be two separate seeds for the two components of a hybrid chem. And very unclear as to where we're going to go with that is I don't know if any of that is in scope for CFRG, but I think some of the specs come from here and some from LAMPs, and it's not very well coordinated. Lots of documents to read that aren't consistent with each other at this time. Thanks,
[00:26:28] Nick Sullivan: Victor. And I wanna echo some of the notes in the the chat here that gave a useful suggestion that PQIP, although it's supposed to be spinning down, this like the consideration of key formats, this is seems like a PQIP issue. Right? Or discussing it. No. I'm I'm seeing no from the audience. But in in any case, if it's a security issue and not an interoperability issue, I think it it has a a strong case to be here. Elliot.
[00:27:01] Eliot Lear: Hi, Elliot Leer. Good morning, everyone. I was actually gonna say something similar because I'm sitting here staring at RFC ninety nine fifty eight, which is post quantum cryptography for for engineers. And the one thing I think this document shouldn't do is reproduce that document. Yes. And the second thing I was going to mention was that anybody who was paying attention to me in the TLS working group will know that as the ICE, I was pretty much jumping up and down with my hair on fire saying, could somebody please write down in a neutral way the issues that are being faced here in terms of hybrid versus non hybrid or what other issues. So if if you're going to cover that here, I think that's great. In fact, I think that's phenomenal. And it's sort of a non neutral in sort of a neutral way to explain the issues and what have you. If that's part of this document, that take that that would be delightful.
[00:28:06] Nick Sullivan: Okay. So one this this suggestion here is if we do decide to have a common document, which there seems to be certain aspects that are shared, one of which would be to document the hybridization hybridization considerations from a security point of view.
[00:28:26] Eliot Lear: Or none.
[00:28:27] Nick Sullivan: For things like binding.
[00:28:28] Eliot Lear: Right. Okay. And that that that would be wonderful. And I I've talked to a couple of different authors who are interest prospective authors. I even have one document in my queue, which I would punt to you guys to say consider this as some as some text or it one of them is from Osama. Another person who might be interested is Tiru who wrote ninety nine fifth co wrote ninety nine fifty eight. So I think you'd get some a substantial support from from those people to add a little bit of text, and I know everybody here would then be in a good position to review it much more so than, say, the independent submissions editor.
[00:29:05] Nick Sullivan: Okay. Thank you. And we invite prospective editors of CFRG documents to reach out to the chairs, we can help coordinate. If there's no other comments on this, we we will take this summary to the list and see how we can move on to adoption. Alright. So after the agenda bash, we have Abhi Shelat.
[00:29:46] Abhi Shelat: Hello. Hello, everybody. Thank you, Nick, and the chairs. So I will begin this, discussion with, an update on our LibCK. The next slide. So just to refresh and identify the problem that, this project is trying to solve. Next slide. So from our experience, there's a strong desire for post quantum zero knowledge scheme. This comes from both the EU and organizations like Apple and Google. I'll let other people speak for Apple, but certainly, there's a very strong concern against cryptographically relevant quantum computer attacks from Google. Google has a quantum computing research group that's been very successful in the last year, for example. And there's a very strong desire to avoid deploying new elliptic curve based cryptography and schemes at least at Google. And so the preference is to choose post quantum schemes when possible. Next slide. So basically, this is my opinion. There's an urgent need for specifying or for researching post quantum georenalge schemes for these applications. And my specific, opinion, which I'm happy to debate and get a, you know, feedback on, is that deploying new elliptic curve cryptography in this year is not a responsible thing to do. And, thus, it's important for a community like this community to provide, solid research on alternatives. Go ahead. Next slide. So I am putting forth the goal to specify and analyze a transparent hash based your knowledge argument system. And it should be, essentially efficient and, you know, practical enough to be used for proving statements about legacy algorithms like ECDSA and SHA two fifty six. So those are the two constraints of the outlines of the basic problem. Next slide. So that's my point one. I'm advocating for this to be a goal for this group. And my second consideration is that, we have provided some concrete starting points for this, this particular document. It the plan has been presented in the last few, sessions. And at each of the sessions, at least in the live sessions, we've received positive feedback, several speakers saying, this is a reasonable thing to do, and this is a reasonable approach to take. The plan now that, we are suggesting is, essentially to split up this current document, which, its latest incarnation is is posted online here. We will move the Fiat Shamir specification to this other draft document that, Michele and, Kathy are, working on, and they have been amenable to, taking these updates. Previously, that document specified essentially Fiat Shamir for Sigma protocols, And now the document will include a section for, IOP inter interactive Oracle proof use cases. So there'll be a generic document that will be derived from this document that specifies the main zero knowledge proof scheme that could include a commitments, a padded sum check, and the security analysis, a companion document specifying parameters, and an external document, for example, specifying, the circuit formats, which we could which could possibly find a different home to be determined. Next document. So just to recall, this Longfellow zero knowledge scheme, it, it's a simple scheme in my opinion. It involves specifying an, interactive protocol, which in our case is a layered sum check, and a commitment scheme, which in our case is LaHero, and essentially combining it using one of the oldest recipes from the literature of this particular paper, which says everything provable is provable in zero knowledge. And, essentially, this box here gives a short synopsis of what the algorithm, basically says. Go ahead. Next slide. The scheme, appears in this eprint document. It also appears in the communications in cryptology journal of the IACR. The, code base is open source. It is have a two implement two independent implementations, one in c plus plus and one in Rust. And, our group at Google is now also reimplementing it in Rust, and we'll be sharing that, shortly. So it'll be the third implementation, which has clarified many of the details in our spec and, essentially improve the code quality. Again, it only relies on the hardness of the SHA two fifty six. And it, as far as we can tell, it is the best, trade off for proof and work in this particular regime, under these constraints for post quantum. Yeah. Next slide. And just to recall what has happened since 01/25, since the last meeting, I'll give a quick next slide. Advance the slide. Yeah. We have been extensively using AI security review tools to review the code base and the spec. And we have made essentially defense in-depth improvements to the code, but we have not identified any real any significant any significant issue. We've rewritten the code in Rust, in fact, to deal with many of these cases like zero sized inputs, zero zero sized circuits, etcetera. We've also formalized parts of our circuit generation in lean. So for example, in our GitHub repo, we have a lean proof in MathLab, which essentially specifies what the circuit that's that verifies an EC DSA circuit is in our proof system and then proves that it's equivalent to the spec. And by equivalent, I mean, we formalize exactly the the completeness gap and the soundness gap in in in those things in those proof statements. And then we've also, experimented with, using Verus to verify some aspects of the Rust implementation. We think both of these tools are very very developed well developed and excellent for this particular use case. So in particular, by the time that, this group cons would consider, Longfellow, we hope that many of the, schemes, scheme security proofs can be can be formalized in lean. At least the reductions, between, like not, for example, a full analysis of a lahero or some check, but, assuming those schemes are correct, how the composition, is is sound. Next step. I think that's it. So I wanna spend the rest of the time essentially for questions.
[00:36:58] Nick Sullivan: Thanks, Abhi. If there are no questions right now, I want to raise to the group the question of the FIA Schmir document and somewhat expanding the scope a little bit. If there's any anybody has any issues with that or complaints, time please raise them now. Okay. Chris Wood.
[00:37:30] Christopher Wood: Hey, Abi. Thanks for the talk. I support the work. Regarding the plan, I think it makes sense. You had can you go back to that slide that had the the plan on it?
[00:37:41] Nick Sullivan: Let's see.
[00:37:43] Christopher Wood: I basically had, like, three items, one of which was, like, the core scheme, a second of which was, like, some parameters, and the third of which was, like, the application specific bits, the circuits. I would collapse the the scheme and parameters into the a single document the CFRG focuses on and then punt, yeah, all the application specific bits to the ITF groups where that happens because that is indeed application specific. With the with the important asterisk and caveat that I think the CFRG document should be written in such a way that it makes developing those circuits easy to do and easy to do correctly without having to be a cryptographer. I don't know what that looks like specifically because in my experience, the circuits are more often where things go wrong. So I think we just need kinda just set people up for success. On the formal verification point, you mentioned that you're doing a lot of work in this space, which is fantastic. Specifically on the lean stuff, you said that you you have this lean spec and you prove equivalence against your implementation, the the c implementation, if if I understood correctly. I was wondering if you could say more about what you've done to ensure that the circuit itself, like, specification is correct beyond just asserting, improving that the the specification matches the implementation? Because it in my mind, they're sort of two separate problems.
[00:39:09] Abhi Shelat: Yeah. So one thing can you can you go back two more slides, Alexi? I think
[00:39:15] Alexey Melnikov: Yes.
[00:39:15] Abhi Shelat: Yeah. This is the slide that oops. One one more. Forward.
[00:39:21] Alexey Melnikov: One forward.
[00:39:22] Abhi Shelat: Yeah. Right here. This slide. Yeah. So just to clear just to repeat what you said, what you're suggesting is that b and c should be in the same document?
[00:39:30] Alexey Melnikov: Yeah.
[00:39:31] Abhi Shelat: Okay. That that I'm I'm open to however the room feels like, and that's fine with us. So as for your second question, which is what have we done in our formal verification? So, yes, there are several components of this. Let me tell you what we have in our GitHub repo today. It reflects essentially the problem you suggested. How can we build circuits that have, high assurance as to what they're achieving? That was the problem. That's where we think all the problems will arise in the scheme, and we have done it for ECDSA. So ECDSA has a NIST specification. You can read how do you verify an ECDSA signature. There are, like, six mathematically, semantically important statements that, you know, statements that have meaning. And we that's where we start. That's what the spec is for ECDSA. Now our circuit for verifying that does it is a particular implementation of it. And in fact, it's quite a different implementation. For example, it checks a different elliptic curve equation than than the one specified in the spec. And, you know, it does it as a slice circuit in like a in a depth 16 circuit versus kind of what the the obvious mathematical interpretation would be, which which would be a very high depth, you know, anytime you do, like, a elliptic, scalar multiplication, it has, like, depth 256 for, like, for 256 bit curve. So our point is that we have proven in that lean thing that our circuit, which we've specified in lean, is equivalent to the spec, and we've established the conditions under which they're equivalent. So there is small gap in completeness. There could be valid signatures that validate under the spec that very small number, like, you know, exponentially small number that do not validate under, for example, our circuit. That's a completeness gap that we can specify in that thing. So that is one line of work doing that for, like, all of our circuits. The SHA two fifty six one is very easy to do. The m doc circuit and MLDSA are, like, more difficult to, for example, give formal proofs that our circuit is matching exactly the semantics of the spec. So that is one line of work proving that circuits are well formed. And, you know, we are we are trying to make that easier as systems. As I said, our Rust based compiler, has has a lot of mechanisms which prevent natural errors like unconstrained values and so forth. The second issue is the Longfellow's zero knowledge, protocol scheme. That, of course, has a bunch of steps. We have a secure a written hand paper and pen, proof in our in our paper that's been validated as several times, but we would like to have that formalized as well. We have tried some parts of that in EZCrypt and then some parts that are algebraic in Lean. And that's that's where we're going with this. And, again, finally, the implementation, we're using Verus. And Verus uses SMT solvers like z three and Singular. And we're seeing that if we can skip lean and, in fact, do all of the validation in Verus, then we can basically, tie our exact REST implementation to exactly the scheme. That's the long term goal, and that's that's we're spending all of our time on right now.
[00:42:29] Christopher Wood: Fantastic. Quick follow-up question then. Do you expect that people will be writing and expressing circuits in Rust and then using the compiler to, produce the output? Okay.
[00:42:38] Abhi Shelat: Yes. Yeah. So all all of the Rust framework essentially helps make sure that you don't make mistakes like having unconstrained bits and so forth.
[00:42:45] Christopher Wood: Fantastic. If possible, do you know how assuming you you you get to that place, let's say there's a new working group like Web Bot Off, for example, that wants to use Longfellow for proving a different type a different relation.
[00:42:58] Stanislav Smyshlyaev: Yep.
[00:43:00] Christopher Wood: If you had everything that you just described, how much work do you think they would need to do in order to produce a circuit that's specific for their needs and then also go through the same sort of verification steps to make sure that it's correct? Would it be a simple matter of just write the script in Rust, or would they have to redo some of the stuff you did in Lean and potentially Verus? Like, how much additional work would they have to do? And I ask because the goal should be to make that basically as lightweight and as minimal as possible because they are, you know, those ones most likely to shoot themselves in the foot here. And, yeah, I'm curious to hear your thoughts on that. That
[00:43:36] Abhi Shelat: would be a golden like, that would be a goal. And in particular, if we specify components like the MLDSA signature verification or or ECDSA signature verification in shot and Merkle trees. If we give a certain set of primitives that already have, these type of errors or lean proofs and the the application developers only gluing them together, you know, that is a big step forward. Of course, there's also problems in composition. I I will lead with this. There are have been at least three groups external to us that have developed circuits. One for a JWT format. We have a version, but some Lucas Han also has a version for essentially ZK JWT. We also have someone who's implemented, like, BIP. There are two BIPs that relate to something that happens in Bitcoin, and people have developed circuits that, you know, validate the statements in those in those BIPs. And those have been without our help. So it is certainly possible for external people to do this, especially with the LLM LLM tools. Like, they essentially give the LLM tool our repo and say, now I wanna change the statement to check this. And then when we look at it at a very you know, we don't do a full audit because those take months. But at a very high level, those things actually work out to be quite reasonable.
[00:44:50] Christopher Wood: Cool. One final comment, if I may. I would suggest an additional bullet on this plan, which is to say maybe having, like, the the the common gadgets and circuits that people use also be something that this group produces because it's it's gonna be likely that everyone is gonna want to use some prove something about an MLDSA signature, for example, enforcing everyone else to, like, redo that seems kinda silly. I'm sure, like, a a hash function, for example, like, there there's probably building blocks that other people want to stitch together compose in their circuits that we could we could basically have, like, a kinda standard library for. And you've kind of already done the work to or you're well on the way of doing all the work to verify those things. So let's just let's just drive it home and then pin them down here, I think.
[00:45:36] Nick Sullivan: So Chris
[00:45:37] Abhi Shelat: Thank you for your comments.
[00:45:40] Nick Sullivan: So so Chris would if with your suggestion in terms of changing this plan, would this sort of necessitate gadgets going into document c, or do you still recommend combining b and c?
[00:45:54] Christopher Wood: I I think if the if c is, like, sort of reframed to be about gadgets, then, yeah, it would have them be separate in that case. But so the sorry, mate. B is the core scheme. C is the circuit or the the core gadgets, like, the the the common circuit components that everyone would use. And then d is, like, you know, the application specific bits that would assemble their circuit based on those gadgets that can happen outside of this group. Does that does that make sense?
[00:46:21] Nick Sullivan: Yep. That makes sense. We we've we've tackled problems like this in various documents that define generic and concrete. Sometimes they've been together, sometimes they've been apart, really depending on the complexity of yeah, how how the concrete specifications are and what what type of parameters there are. So I think my recommendation is to, you know, sync up with the authors for something that's a reasonable split, post it to the list, see if there's there's the same level of support as we've seen previously in these presentations, which is a lot compared to some of the work we have. And and if there's if there's sufficient support for that layout, we can do a call for adoption potentially. Cool.
[00:47:14] Christopher Wood: Yeah. I'll be I'm willing to help with you with it as well if needed.
[00:47:17] Abhi Shelat: Thank you.
[00:47:19] Nick Sullivan: Great. Thanks. Well, Chris, you're gonna have to get back up here. Yeah.
[00:47:43] Christopher Wood: My name on the draft? What? I mean, on the slides? Kinda clicker.
[00:47:49] Nick Sullivan: Yeah. Yes.
[00:47:50] Alexey Melnikov: Hold on one second.
[00:48:00] Christopher Wood: Alright. Hello, folks. Yeah. Thanks for allowing me to go quickly or go first rather. So I'm gonna be talking about our hybrid post quantum authenticated or password authenticated key exchange protocol, APAIC. For those of though you are not familiar with or not acquainted with APAIC, it's a very simple protocol that allows two parties to establish a secure channel, a mutually authenticated secure channel using a low entropy password or secret, which is a pretty cool thing in in principle. Less cool if you don't like passwords, but the reality is that, for better or for worse, passwords are pretty useful in a lot of situations. Shipping today, for example, there are peer to peer device to device scenarios where you want to establish a secure channel using a low entropy pin, for example, to exchange information between these two devices. This happens all the time in IoT like settings and whatnot. And there's also the very common and widely used client to server authentication password use where a client presents a password to authenticate to a server. This is usually a sort of password that's, like, long lived. Unfortunately, user chosen instead of a password manager generated thing and, you know, used in in perpetuity over time. So pakes as a protocol have a number of interesting properties beyond the authentication piece. They have forward secrecy as well. So you establish a secure channel with forward secrecy as we have come to know and love. They have this additional password or property called password hiding, which is to say that, like, an attacker can't, retroactively, when looking at the transcript, recover the password that was used to by both parties to authenticate each other and establish that channel. Pigs can also be symmetric or asymmetric. A symmetric Pig is one in which both parties know the same password as is common in the the device device setting where both parties share a PIN and they, like, they, you know, agree on the PIN out of band. Or more in the client server setting, asymmetric where only one party knows the password and the other party of the server in this particular case happens to know what we call, like, a verifier of the password that they can use to check that the client actually knows the correct password. So pakes are used all over the place. We have a lot of deployments. We have a lot of protocols, SRP, CPaaS, PaaS, two, OQuake or Opaque, rather. All of them, unfortunately, are built on classical primitives. And the reality is that when a quantum computer is readily available at whatever time line that happens to be, the the unfortunate situation is that most of them would break. Some of them would break, much more badly than others. SPECT two, in particular, is, sort of egregiously bad in this particular case, but, nonetheless, they're all sort of vulnerable in this particular way. And you might imagine that, like, say, you you you you could, like, bootstrap or get closer to a a, you know, quantum ready state as it were by, like, combining APAIC with a post quantum key exchange protocol, like, you know, maybe protecting it with, like, or if if you're for to, for example, like, run the PEG inside of a DLS handshake that's doing a post quantum key exchange that maybe you you get some kind of benefit there. And perhaps true that the output shared secret from the PIC is is, you know, protected against the quantum computer, but the, the password itself is not, and that's ultimately a thing that is it's it's sensitive here, especially in these, like, set settings where the the client is using or the client server setting where the the client's using, like, a long lived password over time. Anyways, so, like so depending on the use case, you know, the the the quantum readiness of a particular protocol could be a problem, could not be a problem. So for, like, the device device settings where, you know, we're using things like SPEAK two and CPASE today, it's probably not a problem. You it's not likely that you have a quantum computer sitting right next to you that's ready and willing to, you know, try to, you know, break the transcript, recover the the password that was used exactly once and thrown away to, you know, try to attack the the two parties that are exchanging information. Contrast and settings where you do have long lived passwords that are used, you know, over many, many sessions, the the applicability of a quantum computer in that particular setting is is is very real. So the landscape of post quantum Pigs then is basically research, I would say, at this point. We have standardized chems. We have standardized signatures, but we have no post quantum peak itself that's been standardized. There's been a lot of research in this space. Noise and or noise. Noise. Noise. And OakQuake, which we've worked on. Basically, take a cam and turn it into a PQPake in an EKE like fashion. You have tempo, which is sort of an improvement on that that addresses side channels, timing side channels, and you have various other schemes that combine or compile component pakes into hybrid pakes if you want a set a situation where you have sort of best of both worlds, like classical and post quantum security. But for the most part, there's there's basically no specification, no standard, which is what this draft that we're working on purports to solve, and that its contents are as follows. It has it's been since been sort of rewritten to focus on what we call, like, a black box oriented design where there are, like, black box pics. The first of which is Oakquake, what we're calling Oakquake, which is basically noise and tempo under the hood, and then Oakquake Plus, which is an augmented or asymmetric version of that particular protocol, a hybrid version of Oakquake, is composed with C PACE, run sequentially, and then an augmented version of that as well. Nothing surprising. And we without again, I'm not gonna talk about the details. I think that's, like, for the draft. But the I guess the moral of the story is, like, the we we've we've written it this way because trying to specify exactly one or choose exactly one seemed, you know, bound to fail because of the you know, which pick you want depends very much on your use case, what your threat model is, and whatnot. And the current the the current framing of the draft allows you to sort of pick and choose whichever pick that makes sense for your particular use case and threat model. So let's say you you didn't care about pay hybrid security at all, which is very real and very very much some feedback we heard early on, you could go over just OakQuake or OakQuake Plus depending on whether or not you needed symmetric or asymmetric. Okay. So we presented this a couple times, and the draft is sort of, like, converging. I I would say mostly converged with you know, mean, of course, like, maybe some tiny white wire format details will change, parameters will change, whatever. But for the most part, like, the draft is, like, a cohesive single year unit. We think it's probably ready for a call for adoption. But I guess in in taking a step back, like, there's a lot of stuff in the document that's, like, protocol design work. There's some research stuff, which is, like, how the the the combiner for the PEGs works the combiner for hybrid PEGs work. There's a new notion of a a chem that's relevant for the tempo variant of OakQuake. And, basically, there's, like, some research stuff, and there's some, like, engineering protocol design stuff. And having gone through the pay process in the past and working on Oakquake or Opaque. Sorry. The names are terrible. It it it seemed or it seems like perhaps not best to to repeat the engineering work in this group, especially considering now we have, like, this precedent of trying to keep the researcher stuff here and engineering stuff elsewhere as it's done with CHEMs and HPKE. So my proposal would be as follows, that the CFRG sort of own the problem statement, which is to say build or or, like, specify all the building blocks necessary to instantiate the post quantum peak that would be suitable for all the use cases that are relevant. So if you need, like, a hybrid security or if you need a hybrid deployment of a particular PIC, then it would include, like, the the the combiner stuff. It's very similar to what the the CFRG chem documents are doing today. We'd have the split the the new chem definition that we need for tempo, basically, all that stuff. And then all the engineering bits, which are like, what is the what is the wire format look like for this particular protocol? How do you how do you, like, stitch together C PACE and O Quake actually on the wire to to plug into an application? That could live in a very short lived working group, very similar to HPK. And I think we can target a buff for that next time to kinda get that ball rolling. So this would be my proposal. Curious to hear people have feedback, questions, whatever. Happy to talk about the contents of the draft, but we've presented a couple times. So I was gonna say, hopefully, it's clear, but, like, I haven't talked about it, so perhaps it's not clear. But, anyways, I'll take questions at this time.
[00:57:28] Nick Sullivan: Dan Harkins?
[00:57:32] Dan Harkins: Yeah. Thank you very much. I'm I'm I'm very much in in favor of of this being adopted by the by the research group. There are some changes that I I I think would be would be would be useful. For instance, this this draft, this specified use of of chameleon to to randomize the the the, MLChem public key, but it it does it by using the splitable binary uniform encoded chem, which I think is a a completely unnecessary construct, because it splits out row from the from the the vector of of coefficients in in in the public key. So there's no it's not necessary to to have this abstraction of splitting splitting the binary key in in in in your draft. You can just you you can just call it, you know, at MLChem keygen and then call Chameleon. And and that that that's that's really all you need to do. The other thing that that that I I think would be valuable, and this is really just a a comment on CFRT drafts in in general, but they seem to be starting to be extremely particular in in the the the the the bit format of of of how these things are are are being done. You know, like, c paste did all this stuff with LV cat and stuff, and and your draft is now doing LV encode and LV decode. There's no there's no point in in in specifying a length and a value. Just say, this is the blob that that I'm producing, and that that's what the CFRG should do. And then if if if this draft gets gets incorporated by some ITF working group, they're gonna specify, you know, the length the type length value of how this blob gets gets gets put into the this particular protocol. So this this should really be a tool and not not, you know, you know you you don't need LV encode LV encode LV decode kind of stuff. So I would I'm very much in in in favor of this. And in fact, I've I've I've specified a a version of this this protocol in in eighty two dot eleven to to do a a hybrid PEG. And I I so I'm I'm really in favor of this being adopted, but I I think it should be sort of generalized and and and, you know, completely get rid of of the splitable binary encoded uniform chem thing. Thank you.
[01:00:22] Christopher Wood: On the splitting point, that's exactly what I'm proposing here. Like, things like the wire format details that we needed to actually have something interoperable were included because we didn't have any other place to put them. I agree that the CFRG document is not perhaps the best place to do that, so that's what I aspire to. And, hopefully, like, the application specific encoding or embedding rather can happen elsewhere. For example, if it was gonna go into TLS, that could happen inside TLS. No big deal. On this the sputtable chem, we need it for tempo. We talked about or Yellie talked about this, I don't believe last time, but the time prior, where there's, like, a very obvious and trivial timing attack against the the password if you don't split and then separately encrypt only part of the public key under the password. So we do need that, but perhaps I misunderstood your comment. But in the interest interest of time, I think I'll take Scott, and we discuss offline.
[01:01:10] Scott Fluhrer: K. Scott Fleur, Cisco Systems. I want to express some skepticism about a hybrid PEG because if it requires multiple rounds for it to work, it becomes rather difficult to fit into existing protocols. If that is the case, I would put that as a less important item compared to a post quantum peg, which I agree is rather important.
[01:01:34] Christopher Wood: It's exactly why we wrote it as such. So if you if you want the hybrid, you can use it. If you don't care at all about it, you just you you, like, you know, delete that part of the document, and you still have something you can implement net to end and use it in your use case. We heard the we don't want hybrid feedback very clear last however many times, and so this was our response to that. Some people do want it, and so we this is our compromise. Stefan?
[01:02:01] Stefan Santesson: Yeah. I just wanna quickly voice a very strong support for this work. We really need post quantum variant of of opaque or something that can replace opaque. Just I would really like when we do that in the end. It would be great if it would become a standard and not only an informational document, though. But I really think this is important, and I'm follow it very closely. And if I can help out, that would do.
[01:02:33] Christopher Wood: Great. Thank you.
[01:02:36] Dan Harkins: Rowan May, strongly support this work, and I would be happy to help with the both.
[01:02:40] Christopher Wood: Thanks. Appreciate it. Thanks.
[01:02:42] Nick Sullivan: One quick question, Chris. For these splitable components that you're proposing, what other potential applications are there? Is there are there needs for them within other use cases in the ITF? It's a
[01:02:58] Christopher Wood: good question. I don't know of any offhand for the squiddled chem, for example. That seems very specific to the PIC. And, of course, like, the PIC combiner is obviously very specific to the to the PIC as well. So I don't know if their general purpose in the same way that the the chems are, like, generally applicable to not just HP heap, other stuff. But it seems like the very if you were trying to draw a line between, like, what's what's research and what's not, that seems to be where it's you can cut it cleanly. But I don't know. Maybe some maybe some other application will pop up.
[01:03:30] Nick Sullivan: Okay. I I encourage you to seek seek out given the the view of everything that's happening at the ITF, whether there there are potential use cases for this. But generally, I'm hearing a lot of very positive support. I think we can probably move to adopting this topic pretty quickly.
[01:03:50] Christopher Wood: I think, I guess, order of operations then, I can I can propose a concrete split? So split the document to two and then let you all know or let the list know when that's ready. And then Yeah. We can have some discussion, then maybe go from there?
[01:04:02] Nick Sullivan: Yes.
[01:04:03] Christopher Wood: Great. Cool. Thanks, folks.
[01:04:45] Sofian Brissaud: So hi, everyone. So I wanted to briefly introduce to you the proposal we have for a new hybrid signature. Okay. There are already quite a few proposals. So why another one? We believe it's interesting because we have a bit of a different trade off compared to other hybrid signature proposals that we have identified and also because we have a bit of a different approach considering security, but more on that later. So what we identified to be interesting for a hybrid signature is, of course, you want hybrid and forgeability, and that's the case for the four hybrid signatures identified. You have different trade offs when it comes to strong and forgeability. For instance, composite does not have strong and forgeability because you can break down and then recombine signatures. And our proposal is PQ only, which means that we are not degrading the security of MLDSA. And then we are considering two more security properties, which I will detail afterwards. It's the backward compatibility and interoperability. I have more on that later, but we found them to be interesting. And we are quite satisfying these properties, which is not necessarily the case depending on which of our proposal you look at. And then if you compare everything like signing time and signature sizes, you also have different trade offs. But really to be fair, the difference is just a few percents. It's like 32 bytes out of 2,000 or just 1% signature time. So what we mean with backward compatibility? Yeah. The idea is that you take your hybrid signature scheme, and so you have a hybrid key pair, and you choose to take the, for for instance, ECC part of the keeper, and then you use, for instance, ECGSA or EDDSA to sign with this with this key. And the question is, what happens? Are you degrading the security? Is is it less secure to than if you were using a totally different key pair for the ECC parts. Right? And the goal for backward compatibility is to make it so that you are not losing security. For instance, if you take composite, you can extract an ECC signature from the hybrid signature, and this ECC signature was not produced by the ECC signer. So in a way, you could consider that to be a forgery. And so you want to avoid this kind of situation. Interoperability is kind is defined the same except that you are using the post quantum part of the hybrid signature scheme to reduce post quantum only signing. Okay. So how is defined how is Silithium defined? So the idea I mean, for the key generation, you're going to generate an ECDSA keeper and an MLDSA keeper, and the combination of the two gives you the hybrid keeper. And when you want to sign, you're going to make kind of an MLDSA sandwich with ECC parts at as the bands. So you're going to generate a commitment, a Schnorr commitment, and you're going to put this commitment inside the context string of MLDSA. This gives you so an MLDSA signature, which which has something called I mean, you have the challenge from the MLDSA signature, so you can use each this challenge as if it was the Schnorr challenge. And so you answer it. This gives you a response z one, and you put it along with the MLDSA signature, and this gives you the whole Silithium signature. Then when you want to verify, you're going to just recover the Schnorr commitment, and then you're going to just run MLDSA verification with, once again, the specific context context context string, which is quite important because it embeds the verification key of the ECC part of the scheme and the commitment. So it's really binding the MLDSA signature to the ECC part of the scheme. Right? And now for concrete instances, for now, we are proposing to use MLDSA 54 well, four four and p two fifty six the p two fifty six curve and etcetera, etcetera, when we are going to higher security levels. But there's actually no reason not to use any of the curves. There were a few questions about using, for instance, the IETF curves, and this is not an issue. And even if you want to swap ECDSA with EDSA, there's no issue with that. Actually, the research paper we wrote was actually considering using Silithium with the Schnorr signature, and EDSA is much closer to the Schnorr signature than ECDSA. So there's no no issue. The question that we have is that if we were to define a curve twin two fifty five nineteen variant is whether the nonce generation inside of Silithium should be closer to the one in at DSA or not. So do you want something that generates a deterministic nonce using SHA five twelve, or should we move it to SHA three so we avoid SHA 50, SHA five twelve altogether or just keep it as random nonce? This is something we would be looking for feedback on. And another remark we had from the community is that the ECC part of the scheme is not black box. We are really took parts of ECC signature schemes and put it around NLDSA. We don't think that this is an issue because all the operations that we are using, you need to implement them when you are implementing ECGS or RDSA. So we expect that in most implementations, they will be available for use because this is I mean, it's going to be inside of your library of your crypto library. And assuming that you have all of those things available, it's not very hard to implement the the scheme. For instance, we did the REST implementation, which took less than 150 lines of codes. So that's not a lot for the whole scheme. So just to detail a bit on the security properties like backwards compatibility and interoperability. So what's what's going on? So the the way we see things is that, alright. So can we use the ECC part of the scheme and sign with ECDSA or EDSA, and does it create any security issue, like in Composite, for instance? And the answer is that no. There is no there is no issue except if somehow with ECGS with ECGS signatures, you make it easier to recover the signing key, which to my knowledge is not the case. You can think about it. The argument is like, and EDSA, are based on zero knowledge protocols. So signing does not reveal any info on the signing key. So having access to such signatures is totally useless to recover the signing key. So it's as if you I mean, you can just get rid of all the signatures you get, and they they do not help you forge all the signatures. The question about interoperability, so using the post quantum parts of the scheme, is a little bit different because since we are using MLDSA as a black box, well, you can technically extract an MLDSA signature from a Silithium signature. But the fact is that we put the commitments w and w one inside of the context string. So the context string is totally unpredictable because it has very high entropy. So as long as you do not allow during verification someone to submit the context string they want you to verify on, then you're going to be fine because you have it's it's going to be very difficult to land on a specific context string. So this this is fine, but you just have to be careful about your application. Then there are just a few questions we want feedback on. So for instance, we have different trade offs of security that we can go for. For instance, if you prefer, the commitments could be appended to the message instead of the context string because now you have a message which become unpredictable and the context string is fixed. So maybe it makes it easier to filter out signatures that are extracted from Silithium. I don't know. Or in the research paper, the proposal was a bit different. It's it's required a specific implementation of MLDSA. We wanted external mu and the ability to update the signing key of MLDSA. But then we have no assumption on what you're doing with the signature for interoperability. You can use the free signature schemes at once without any security issues at the cost of having some assumptions on your MLDSA implementation. So is any of those two options more attractive than the current one? Do you want a context string? For now, there is none, but we can we are not using the whole length of the context string from MLDSA, so we could use that. So do you want it? And I think that's it. So I'm just summing up all the questions that we have for the community if there is some if there is interest in in solution. That's it. Thank you. And I have some appendix if you want to see the original proposal.
[01:15:37] Scott Fluhrer: Okay. Scott Fleur, Cisco Systems. You had a bunch of questions. First one is EDDSA random context versus deterministic. The whole reason that EDDSA uses a deterministic announced based on the message is to avoid issues if you don't have good randomness. I have not gone through your construction to see if what happens if you repeat nonces accidentally. If you do have issues, you probably want to go deterministic for all curves, not only the two five five one nine. If you don't, you probably want to just just you don't want to parse through the message twice when signing. And for your questions about context, I believe slide nine. If you append the the context to the message, that is pretty much what the that very similar to what composite does with with the signature. You it had you're dropping back to the same security that you that the signer could listen in to to to that on a pure message and re and refuse to sign it. You complained that that you didn't like that property, but you're going back to the exact same property. Thirdly, about context strings have limited to two fifty five. If you need more, apply your favorite hash function to it to reduce it to a and there you go. So you're in practice, you're not particularly limited. Thank you.
[01:17:26] Sofian Brissaud: Alright. Thank you. So, yeah, since this is based on Schnorr and, I mean, MLDSA, of course, we are subject to problem if you repeat the nonce. So, of course, you would at least need to generate the nonce in a hedged way, for instance, taking inspiration from MLDSA or move to deterministic generation. Yes. Thank you. Just considering the context. Right. Thank you for the feedback on context.
[01:17:57] John Preuß Mattsson: Yeah. John, on the question on on nonsense, whether you should go purely random or deterministic, I think neither. I think you should go hedged. Scott explained why purely random is bad, but we have had a lot of discussion here. And I some IoT people with hands on knowledge about devices, they say, I I would I will will never implement and deploy a deterministic algorithm because of side channels. So I think hedge is the answer. More high level question. Now we have I think it's very good discussion. Now we have, I think, at least three different drafts proposing composite signatures here in CFRG. How do we move forward? Do we have, like, adoption call for some of them, or do we have a more coordinated design team and and group that, like, shows one of them for for adoption? That's more a question to the chairs and the group.
[01:19:02] Nick Sullivan: Okay. Thanks. Yeah. And by the way, there is an adopted draft about hedged ECDSA and EDDSA that you could take a look at in in the CFRG.
[01:19:13] Sofian Brissaud: Yes. Thank you. So about hedged, when I said when it will when I wrote random, I actually had hedged in mind. Sorry. That's
[01:19:20] Nick Sullivan: Yeah. I think we're all at that point now. Yeah.
[01:19:25] Steffen Kittel: So if you should meet Google, I will repeat the statement that I also made on the list. I think this is really great work. I think that if we do a hybrid, this is a really nice hybrid to use. The problem that I have is I have way too many hybrids. Like, they like, at the moment, it kinda looks like the last one is winning just by by the virtue of being the first. I'm not sure how much I like having more hybrids just because the interoperability is going to be a nightmare already.
[01:20:01] Sofian Brissaud: Yes. So I totally understand the hybrid overload. And the thing is wait. The last the last column of my of this table at the beginning is a construction that is very close to. Instead of extracting the challenge from MLDSA, you hash the whole signature to get your challenge. And with this trick, you can achieve post quantum plus classical security for strong unforgeability. And so I think at least comparing these two schemes is a bit straightforward. So I think it's going to be somewhat easy to decide if one I mean, which one should move forward, and I think it's not very necessary to keep the two. Then when it comes to composite and MoTMA, the trade offs are somewhat different. So maybe it's a bit more difficult to decide which one should move forward. But I think at least the first and the last columns are quite easy to compare. And so I just
[01:21:06] Nick Sullivan: Great. And we can leave this up for the the chair questions, which were very well framed by John and Sophie's comments. There have been composite signatures that have progressed pretty far within the IETF right now. This question probably should have been brought to the group maybe two years ago, three years ago, five years ago. Who knows? But so I wanna raise a show of hands here in the in the show in the vote here. Just is the topic of hybrid PQT signature something the CFRG should explore adopting? And this is gonna be a yes or no question, and I'll let folks vote. This is to step back and look overall at the CFRG's potential contribution to this space, And and this is a useful chart to have for this question. Alright. Voting now. Okay. Five more seconds. Get your votes in. They're still rolling in. Okay. So the show of hands shows that this topic has significant amount of interest. More than half of the votes were were yes. There were more no's than I'm usually comfortable with for something like this. So I I think it's it's worth having this discussion on the mailing list, especially in the context of what's already happened in the ITF. And the discussion more generally about hybrid PQT signatures has to be settled before we are able to, you know, make determinations as to which which documents to pursue within the topic. So thank you very much. Thank you. And Thank you. Moving on to the next one.
[01:24:08] Alexey Melnikov: Who's who's
[01:24:09] Nick Sullivan: presenting? Three.
[01:24:12] Alexey Melnikov: Let's get him a year.
[01:24:13] Nick Sullivan: I think yeah. I believe so. He's not here. Yuri, are you here? Yeah. Valeria, are are you willing to step up? We should we just move to the next one and and Okay. And revisit once we have confirmation?
[01:25:31] Emil Nygren: Hello. My name is Emil. I'm from Ubico. And thank you. And I'm here to talk about ARKG, which is a let's see. How does this work? Oh, I'm holding it upside down.
[01:25:49] Alexey Melnikov: Okay.
[01:25:49] Emil Nygren: ARKG, which is short for asynchronous remote key generation. It is an algorithm or rather a framework for constructing algorithms for essentially like a CAM bot for asymmetric keys. And I presented about this at the last night at IETF, but it was a bit rushed. So I'll repeat some of that here and and add some additional context about what's happened since then. So, in short, a summary of what it is and how it works. It is a thing that allows you to delegate generation of public keys without giving access to the corresponding private keys. So, for example, you can have some kind of hardware security device which puts out a seed value. Then you can use that seed value in software to derive a public key together with a key handle. And then you can use the public key to register with some kind of third party, like a certificate authority or a service or whatever. And then later, you can send the key handle back to the original hardware device or the thing that has the seed. And then that piece can derive the corresponding private key and use that in protocols to authenticate or assign things or do a chem or something like that. And the interesting part of it is that this part where you generate public keys and key handles, you can do that any number of times without having to call back to the original source of the seed. And that's where the asynchronous and name comes from. You can do this and then later derive the private keys. So this is most useful in applications where it's useful to have a, be able to generate public keys long in advance of when you need to use the corresponding private keys. And the way it works is essentially it's a chem combined with a key blinding scheme. So you first agree on a chem and a base key. And then you can generate blinding factors for the blinding scheme, blind the base key, and then encapsulate the blinding factor to be sent back to the original device. And there's a bit of background to this. This is not entirely new. Ultimately, this was this was based on BIP32 from Bitcoin, which uses this kind of technique to do what's called stealth addresses in Bitcoin. And in 2019, my colleagues suggested the way you can use this kind of technique to do background sorry, backup keys in WebAuthn. And at the time, were we were not able to find a security proof for this key generation primitive as it on its own, just BIP32 as a whole. So we partnered with some researchers who came up with a security proof for this, which was published in 2020. And then after that, there's been additional work on that to do post quantum generalizations of the scheme as well. And that point was essentially when we figured, you know, this makes sense to bring up to IETF or IETF rather. And that was also at the same time as we were considering using this for practical use in EU digital identity. So, yeah, the motivating use case for this was to use in your digital identity, where you can use this kind of thing to do less linkable keys for digital identities. The idea is that you have a digital identity document bound to a private, bound to a public key that you use to authenticate that you own the ID document. But then you have, you do that with just easy to say, for example, then of course, the public key is a correlation handle, so you can only use it once. So this technique allows you to generate lots of public keys, bind each one to a unique copy of the ID document, use each copy of those only once. And that allows you to have at least less linkable identity presentations. And the ARKD also allows you to, when you run out of those unique copies, you can generate new public keys and use a refresh token or something to ask a certification authority or something to give you new copies without having to call out to the secure hardware device every time you need to do that. And also, like I said at the beginning, the original use case we envisioned for this was using for backup keys. We don't have a concrete implementation of that. But it's the thing that you could use this for, where you can have we can have two keys and you delegate one of them. One of them gives the other this seed value that it can use to register both itself and the backup at the same time without having to communicate in real time with a backup key, essentially. So this is being rolled out actually. The implementation status is that this is available as a tech preview in YubiKey 5.8, which released yesterday, incidentally. The concrete instantiation of this is based on ECDSA or on the P256 curve. But as I said earlier, there are there is research and concrete instantiations that are post quantum compatible as well. So this is ready for post quantum instances, but we don't have any defined in the draft at the moment. And like I said, the motivating use case is UDI. So we have a prototype of this working in WW Wallet and Serious ID. And we're likely later to also integrate that with Longfellow, to use Longfellow for the main proof and use this to generate the keys that you then bind into Longfellow. Or possibly same thing with VBS with easily SA device binding. So that's the implementation status of this. And the contributions of this draft is to make a concrete construction of the ARKG from the from the research literature and define a couple of initial instances based on elliptic curves at the moment. But it is a general purpose key generation primitive, like I said, kind of like a CAM, but for asymmetric keys. The construction here is modular and ready for post quantum instances. We don't have any in the draft. But it's just quotation marks, matter of defining those instances and adding algorithm identifiers and such for them. And what's happened since IETF twenty one point two five last time is the biggest change is adding, actually, writing out some of the security and privacy considerations. So we've added considerations around what the security properties are and under what conditions they hold and don't. What values are secret and how secret, because some of the, like we derive ECDSA or ECDH shared secrets and chem keys and stuff like that. And these, you don't really need to keep those secret, actually. So there's a security consideration section on which values you need to keep secret and which ones you can and can't reveal and what that allows you to do and so on. There's a section on ChEM ciphertext integrity, which is a thing we introduced in the DES draft as an idea just to help ensure correctness of the the scheme. It's not a security property, but just a correctness thing that we use. And that section explains how we use that and why. And similar, how, under which circumstances you should keep the public seed secret, because they're a public thing in the name, and the scheme remains secure, even if the seeds are public. But there are reasons you might want to keep them somewhat secret in some cases. So those are in the privacy considerations now as well. And then some minor editorial stuff like clarifying things and with examples. But there have been no implementation affecting changes since draft nine, which was a year ago. So it's quite stable, in my opinion. And, yeah, I would like to see this adopted by the research group. So I would like to ask for volunteers to review. And that is the entire presentation.
[01:34:48] Nick Sullivan: Okay. Thanks, John Bradley.
[01:34:58] John Bradley: John Bradley, one of the co authors. I just want to make a couple of observations. ARKG is not what we think the best long term solution for verifiable credentials is. It's just the best solution we have now. We're we're also Emil and I are also working with Google on Longfellow and various other people on BBS as you will recall. So we think zero knowledge proofs are the better way forward, but aren't currently in a deployable state. We are pushing that forward as fast as we can. But for current EUDI deployments where we have to have non core verifier non correlation, batch issuance is the best option. And for cloud HSMs and for various secure elements, this is the best technique that we can that we have that we can currently deploy. I also have a small I have a handful of the security keys that implement ARKG with the web auth and raw signing extension. If people want to play with it, then I could have a couple that I can hand out. But we think that this is ready for adoption. It probably you know, we've been working with a number of cryptographers who you well, well, are well known to this organization. There is a post quantum path. It's not ready right now, but we see it. We think this cryptographic technique probably on its own merit outside of verifiable credentials probably does have some sort of future. But, you know, until it's formalized by the IETF, it's hard for people to start saying, oh, yes. I can use it in this way, in this protocol. So people, yeah, people need to have the confidence in the cons that the construction is correct.
[01:37:14] Nick Sullivan: Okay. Thanks. For for the authors, how would you if you if you know, we've been discussing this on almost every draft so far, but how how would you describe this draft in terms of breakdown, in terms of which is what's pure engineering versus which aspects are like novel research that need to be validated?
[01:37:36] Emil Nygren: None of this is novel research. It's based on
[01:37:40] Nick Sullivan: on Or sorry. I don't mean novel research, but I mean, which part is sort of restating or connecting published research to the engineering challenges Okay. Versus just writing them out?
[01:37:53] Emil Nygren: Yeah. So most of the draft is connecting to the research. There's one section in the draft which is titled COSE Bindings, which is the engineering bindings for wire formats and that kind of thing. And if that's more appropriate to have in a separate document, I'm happy to move that out. But I was told that it's this draft can and should do those registrations, so I kept it in for for now. But those are all of that is localized into the the section title as such.
[01:38:25] Nick Sullivan: Okay. Yeah. It it's typically IANA registries for ITF working groups are not updated by CFRG documents as they're informational. And individual working groups within the ITF are not typically CFRG is typically the base base document and something like type registrations would be something the CoSE working group, I I would imagine, would would work on. And then the second question is, like, from if you were to kinda distill down from an abstract perspective, like, problem does this does the CFRG looking at this solve for the IETF or the broader community? Like, how would you, like, a sentence describe that?
[01:39:12] Emil Nygren: Essentially, it allows you to to have hardware bound keys with less of the hassle of hardware bound keys, in that you can set up a connection or set up a cryptographic connection between the hardware key and something that uses the public keys that doesn't need to invoke the hardware every time. So, for example, you don't need to perform a user gesture every time you need to generate a public key. Kind of the practical problem, like the user experience problem that this is meant to solve.
[01:39:48] Nick Sullivan: Okay. Any other questions or comments on this? Yeah. I think the follow-up should be a list discussion. And as as was noted here, you know, the shape of what adoption looks like in CFRG is adopting a problem space for the most part or at least structured in that in that way. So let's try to have that discussion and see what the group has to say.
[01:40:13] Emil Nygren: So before we move on, can we have a couple of volunteers to review?
[01:40:18] Nick Sullivan: Is anyone oh, maybe we can just do this. Has anyone read the document in this room? Raise your hand. Okay. So we have very few. One hand, maybe? It could Two hands? Okay. One and a half. Three. Alright. Great.
[01:40:33] Sofian Brissaud: Okay. It's 4. Any 4?
[01:40:36] Nick Sullivan: Okay. Let me see 5. Let me see six. Okay. So I guess I guess post let let's start this discussion on the list and encourage folks to read the document before engaging with the discussion with their opinions so that they're informed. Yep. Thank you.
[01:40:55] Stefan Santesson: Thank you.
[01:40:58] Alexey Melnikov: Cool. Ask Valeri to
[01:41:00] Nick Sullivan: Valeri? Okay. We have a different quake.
[01:41:21] Stanislav Smyshlyaev: Okay. Hello. This is not full disclaimer. This is not mine slides. This is not mine presentation. It was prepared by Yuri Blumenthal. And as a protocol, I will be talking about is developed by him. I'm only presenter because he's unable to to make presentations himself and asked me to be a presenter. So all credits about this protocol and the slides should be attributed to Yuri. And so all possible mistakes and some ambiguities in the presentation should be attributed to me. So let's start. So this is a presentation about camp based authentication protocol. Authenticated exchange protocol is authentication based on GEMS. It's called PQuAKE. And so the problem with migration that's was a problem of migration to post quantum cryptography is authentication because, well, with ephemeral cams, it's quite naturally going to the protocols. But signatures are much larger, at least for the currently standardized MLGC comparing to MLChem signature and public keys are much larger than public chem public keys and ciphertext, and they're also much slower. And thus, the current the current properties, if you want to replace signatures, traditional signature with post quantum signatures, it can be very costly for some protocols. Where where it is in particular costly? So for the problematic the problem is that if you just replace signatures that some protocols don't do, don't behave very good with quantum signatures. And there are some ways to if you use hybrid chem, then you have even larger signatures. And for example, you can have a way around to deal with quantum threat and use a shared keys, but it doesn't scale well. And if you have some protocol specific fixes, it is can be very problematic and generic general and very specific to a concrete protocol. So where, in particular, these size of the signatures bytes. It's mostly bytes in constrained devices. It because it enlarges most bytes of the wire and enlarges the quarter footprint for these devices. It also very much bytes on the high speed, for example, high speed VPN gateways, which need to perform a lot of connections in the short period of time. And thus, the performance degradation that was current currently available post quantum signature brings and a larger handshake messages makes this slower. So what can we do about this? So Yuri made some analysis, a paper about the performance comparison of signature based post quantum of post quantum signatures in IQ two compared to chem based authentication IQ two. So there is a draft in group. And on this draft, Yuri based his analysis. A draft about chem based authentication based the draft really just
[01:45:51] Emil Nygren: brings
[01:45:52] Stanislav Smyshlyaev: this protocol integrated with IQ two. And based on this analysis, Yuri published pre published well, it is freely available on GitHub paper. And it showed that if chem based analysis chem based authentication would used in IQ two, It would reduce significantly the can check message size and the time to needed to for cryptic calculation in IQ two about if, for example, if MLKM is used as a decoration of time is 63%. And it also decreases the size of the messages. It also allows us to use classic Macales with preloaded public keys because it's it has a very short a very short ciphertext for to be used as for authentication. And it's also easy to certify It can based authentication products because they don't have to have signature the codes that the codes that produce signatures, it only have to have codes that verify signature for verifying public key key and public keys that are in certificates. But the signing code is can be missing. So it's smaller footprint, smaller space for additional bugs, easy to certify. And what what building blocks should this protocol provide? So it should provide combined online authentication, transcript bound keys, identity protection, and it should be approved in a way that can be reproduced. So the protocol is called PQuAKE. It is published in the draft, an individual draft in. So you can read the draft and see what is it. So there are three basic steps. So first, an ephemeral key exchange that established session key, then exchange of chem based chem chem certificates chem public keys, and then exchange with encrypted with ciphertext and then complete HMAC key confirmation with using this exchanged ciphertext. So it's four steps. Here's a depiction of how it how it happens. So first, first ephemeral chem, then exchange of encrypted and this is ephemeral chem that provides protection identity protection against passive attacks and also against active attack if it is done properly. Active attack for one for one recipient. And then authenticated chems, exchange of ciphertext using this old 10 public keys, GEMS public keys on certificates, and then key confirmation phase. It's rather simple protocol. So there is there are some proofs made by Yuri. It is there are proofs using a cryptic and very fall. And so the proofs proves the following properties, following five properties of the protocol. So session secrecy and mutual authentication, forward secrecy, key freshness, and identity hiding. And could to very few computational game based analysis, and very far uses some symbolic model, symbolic model. So where this protocol can be used as a framework? It can be used in ITF protocols like IQ two, and there is already a draft about this. And it can be used in a doc. And I know that a doc has a very similar can based authentication draft that is very similar to it is very simple to Quick. It's very much related. It can be also used in EEP. I don't know if there is any draft yet, but but still. So the question to that you want to ask before adoption. So is this construction sound? Then other assumptions that were used for proving this protocol are correct. So in CCA two, I guess CCA two, implicit rejection, random Oracle PDF, and HMARK as. Is identity hygiene is done correct? Is it is it needed for both passive and active attacker? So what is composition? Is the composition right? And so the proof artifacts, so anyone can reproduce it and try to verify to to reproduce the proof of this protocol. So and adoption scope. So I think that Yuri is in favor of asking for adoption. This draft into CFRG, is the right place for such verticals. So I I believe it's all. Thank you.
[01:51:47] Nick Sullivan: Okay. Any questions? And thanks for presenting, Flarey.
[01:51:56] John Preuß Mattsson: Hi. I agree with the analysis that chem based authentication can be very useful for mostly for new systems where you don't use PKI, then you have only one algorithm and everything work. The slides use ad hoc a lot. Ed Lake working group has just adopted a chem based authentication, PHY message more similar to chem TLS people probably know of. If I remember the differences between this exact protocol and and Kent TLS and what Lake has adopted is that this assume that you have some shared secret that you use for identity protection, whereas Kent Ellis and the Lake adopt the draft from Lydia at all doesn't assume that. So you get five messages. So I I think I I don't have anything against this, but I don't think Lake is interested as much as stated here. And also for EAP, as soon as Lake has standardized chem based authentication, that would be automatically usable in EAP with EAP ad hoc method, which I think is probably in the publication queue. Yeah.
[01:53:18] Stanislav Smyshlyaev: Great. Thank you.
[01:53:25] Thom Wiggers: Hello. As author of ChemTLS, I'm, of course, enthusiastic about this whole concept. I very much support the point that chem based authentication can be more efficient than signatures, though there's some stuff with, like, how do you then authenticate the chem site the chem authentication key, etcetera. It seems very situation specific what is the best solution in particular protocols. So in the I p two proposals, there discussions about, okay, how do we handle the identity hiding that is required, and how do we balance that with a number of round trips? Other protocols might be less concerned with such properties. I want to do it in fewer round trips. Protocols have their own ideas about how they want to handle their transcripts. For example, I p two does this very differently from TLS, and that has huge effects on the way that you need to prove the security. So I'm not entirely sure if CFRG is the if there is a truly generic form that you can pull out. And if the if then if there is no such form, I'm not sure if CFRG is the right spot.
[01:54:45] Alexey Melnikov: Hi.
[01:54:52] Goutam Paul: Here's Guling from Huawei International. Yeah. I'm also a co author for the game based authentication for IKEV tool. So we have a lot of discussions with Euro and also his other colleagues. So we do believe, yeah, Kilometers based authentication is a good message, at least for some scenarios. Because we have a concern, like, special, like, is this one. Once the commuting communication parties can pre download the term public key key from the other side. In that case, it exceed a lot of communication and also quite a lot of computation power as well. Now because for some scenarios, especially if for the communicating parties, The only can rely on battery, not continuous power. In that case, it will means a lot. So we do think maybe it's good idea to can say the Kilometers based or p q p q k m here. Yeah. So for CFRG. But, yeah, I think maybe one thing, yeah, you may need to consider is that also can say the the proposal from Tom and Wiggers, right, in TLSG working group, whether they can unify the whole framework. I can say that together, they will be good. So use for even use for for I t l s, IPSec, and also some other working groups. Yeah. We can discuss more. Yeah. Thanks.
[01:56:38] Stanislav Smyshlyaev: Thank you.
[01:56:39] Nick Sullivan: Great. Thanks. So oh, wait, John. We have one more question from John John Gray. Hold up, Valerie.
[01:56:45] John Gray: Yeah. Hi. It's John Gray from Entrust. I'd say I support this work. I think it opens up another interesting use case for chem certificates because we know people will do weird and wonderful things. And having, you know, some kind of a draft or guidance and, you know, showing the good way to do this will be helpful because people will find the bad way to do things. So thank you.
[01:57:07] Nick Sullivan: Okay. Thank you. Yeah. So it it seems like there's some positive feedback about this general idea, but not a lot of clarity around the use cases and the, I guess, degrees of freedom for solving this problem. So I think yeah. I think we need more discussion about what we actually wanna solve with this, what scope of aspects we want to consider when regarding chem based authentication before settling on a scheme in particular. So I think this is a discussion that's worth having on the list and and there's definitely some interest in the idea, not only from TLS and clearly from iQV two. There is real applicability of this that could benefit from a shared framework or a shared baseline. But the the size of that baseline and the boundaries within it are are very unclear at this point. So I think more discussion is useful on this going forward. Thanks for the presentation.
[01:58:17] Alexey Melnikov: Do we want any other questions? We have a
[01:58:25] John Bradley: or b.
[01:58:29] Alexey Melnikov: So we will have another one hour session on Friday, if any quick AOBs in the last two minutes. If not, then we're done. Thank you.
Session Date/Time: 24 Jul 2026 09:30
[00:00:43] Stanislav Smyshlyaev: So morning. Right? Good morning. It's a Friday, a very long week. And it's the second session of CFRG. And the echo here is horrible, so I can barely hear what I say other than hearing it's quite loud toward you somewhere. So welcome to CFRG session. We're just going to briefly remind you that we're still on the content of codex and not well. And this session, again, is being recorded and will be posted on YouTube. And please don't forget about code of conduct. We use the best technical judgment and be nice to each other. Okay. With that, we have one hour and four presentations today. So let's get started.
[00:02:10] Felix Günther: Should work. Hi. Good morning, everyone. This is Felix Gunther from IBM Research, and I'm going to give you an update on the chameleon encodings draft. This is coauthored with Douglas Stebila and Shannon Veitch. So for some intro background, if the clicker is working.
[00:02:29] Stanislav Smyshlyaev: Yeah.
[00:02:30] Felix Günther: There we go. So Chameleon gives you encodings that can turn ML-KEM public keys and ciphertext into random looking byte strings. Motivation for that is that ML-KEM public keys and ciphertext don't look uniformly random, and so they can be distinguished on the wire, which is a problem in situations. So think of Chameleon as the quantum safe analog of using Alligator for elliptic curve points just like it's for ML-KEM. And they use this accordingly, so you wanna see this in fully encrypted protocols, for example, for censorship, resistance, avoidance, trying to hide metadata, but also it shows up in pakes, For example, the draft on post quantum and hybrid password authenticated key exchange that Chris Wood presented on Wednesday is using Chameleon to encode ML-KEM public keys. I will not go into the technical kind of details how the encoding works, but just to give you a brief summary is kinda you accumulate the coefficients in in the ML-KEM vectors into a big integer, and then you represent that integer uniformly, or you do rejection sampling. There's many variants how you can do this. So one goal of this draft was to narrow down the choices that we have there, and we did this with the zero one revision earlier this year. There we go. So since version one, we now kind of define the main the main chameleon encoding, which is now in section four of the draft. This was previously called non rejecting, and it's turned out to be with three discussions, the draft the version that people are kind of most interested in. So here, the accumulation into a large integer gives you, like, an n bit integer that you then represent redundantly in n plus two sorry, in n plus t bits overall. This follows a technique already used in alligator squared and gives you that the result is uniformly distributed with a statistical distance at most to the minus t from uniform. That still gives you kind of an opt to tweak. So in the latest revision zero two, we proposed to fix t to a specific value. The proposal here is fixed at two seventy six. I'll give you some rationale, but we also wanna appreciate kind of feedback and comments on that. We already get some discussion on the list. We're happy to discuss this more. So why fixing it in the first place? This avoids kind of a tunable parameter that could be said wrongly. So for example, it could be said way too small or not bite aligned. And full disclaimer, we ourselves had it initially not bite aligned by mistake. So, you know, this this happens, and so this version now ensures byte alignment, and it does so in such a way that the resulting output sizes, like a chameleon encoded public key, will have the same size as a regular ML-KEM public key, and we think that potentially interesting and relevant for employment setting. The resulting distribution then, accordingly, the statistical distance of that is at most to the minus 76. Important emphasis here is on statistical, so you cannot lower this distance with computational power a question like, how many things can you observe? This seems fine for censorship avoidance. For pigs, we're a bit on a discussion on the list already, whether it's the right choice or whether we should also allow larger choices for settings that needed. So comments and feedback on that, appreciated. So with the current setting, the output sizes here are you have the same size for public keys as regular ML-KEM. For ciphertext, you get larger sizes because in to get to uniform distribution, you actually first have to decompress the ciphertexts, which blows them up quite a bit. This also motivates a second variant, which is still in the draft. I'm kinda pushed to a separate variant section. This is actually the original chameleon encoding from the research work behind this. So previously, it was called, like, the rejection like, just the chameleon encoding. Now we call it, like, the rejection variant if you want. And that's tailored at yielding smaller outputs at the cost of doing rejection sampling so you don't perfectly encode always. You don't have a perfect success rate as with the main encoding. So the result of that is slightly smaller encoded encapsulation of public keys even compared to main ML-KEM and slightly larger savings on on the ciphertext size. Again, here, not much of that changed, but we bumped this in the latest version to ensure byte alignment and kinda introduced mechanisms to randomize and clear the unused bits in the top byte for that encoding as well. Then there's also a deterministic variant for Chameleon in case you wanna kinda always encode a ciphertext in the same way. You can derive randomness deterministically from the shared secret. This is specified in, again, part of the separate section now, 5.2. So for an overall picture of the properties, using in the first row here ML-KEM in gray as kind of the baseline, the output sizes for public keys and ciphertext. Chameleon encodings as of the second draft now give you same size public keys and notably increased ciphertext due to the decompression needed, whereas if you want smaller output sizes, then the rejection variant allows you to do that, saving a little bit on the public key size and a bit more on the ciphertext side at the cost of a reduced success probability, similar to kind of what you had for Alligator and doing arithmetic over larger integers. On the further update side, we have put up an implementation of this. We are aware of some previous implementation that might be updated, and so questions where there's comparison possible. One question that appeared there thinking about how to compare this is a question on randomness generation. Currently, in the spec, we use quite generic notation to sample randomness. This is used, for example, in the decompression step for ciphertext. This gives a lot of flexibility in how to implement that, but possibly hinders comparing implementations on the sampling randomness size. So one point where we'd like feedback from the research group would be if there's a particular choice that people would like the draft to make on how randomness generation is specified in the draft. And then coming back to the earlier point, on the main variant, do you have any comments on the statistical distance fixed to a specific value, for example, the proposed d = 76 as in the draft right now, versus having a tunable element here, a tunable parameter? Comments on that would also be appreciated either here on the list. That's all already, and I'll take questions and comments if you have.
[00:09:43] Stanislav Smyshlyaev: Chris.
[00:09:44] Chris Wood: Hey, Chris Wood. Thanks. You probably saw the exchange on this with Michael. Did you see his last message?
[00:09:50] Felix Günther: I saw his last message. I still have to follow-up with him because I'm not sure the the attack that Michael described works the way as I understood it. So, basically, the question is how much can you parallelize password guessing Yeah. And how much does that give you on a single password versus kinda like across the band. So let's look into that. But, yeah, one one option to possibly, like, approach this would be either to fix a larger parameter or to allow tuning it. So if you have thoughts on that and comments.
[00:10:21] Chris Wood: I I think a tunable with some reasonable guidance would make sense, especially because the other documents that might consume it would be in CFRG and could, you know, make reasonable assumptions. It's not like it'd be tunable outside of a CFRG protocol. So and the discussion with my co authors on the 76 as well. That seems like a desirable thing. So I don't have opinions on what that looks like, but I'm sure we can come up with some reasonable text.
[00:10:45] Felix Günther: Okay. Cheers.
[00:10:49] Scott Fluhrer: Scott Fluhrer, Cisco Systems. One of the things which are would be rather important to analyze would be the what is the actual variation between the the completely random and the statistical distance you have. If the only distinct distinguisher is take a look at two to two to 76 squared outputs, and with that, you can possibly determine if it's random or not. If that is the only case, then two to to some what you have is actually massively overkill. If if it's it has a different distinguisher, that is, say, you have a probability of two to the minus one seventy six of being absolutely certain, then maybe two to the minus 76 is appropriate.
[00:11:36] Felix Günther: Right. So my understanding is that distribution is flattened out, but I'm happy to discuss this more of to to see whether 76 by other arguments can be kind of bumped to a reasonable bound.
[00:11:55] Stanislav Smyshlyaev: Alright. Thank you very much. Okay. So So VPSs are going to be remote. Alright. For for the next presentation, I assume it's remote. Who I can pass the token. Yes.
[00:12:58] Vasilis Kalos: Hello. Can you hear me? Okay.
[00:13:09] Stanislav Smyshlyaev: Alright. Hold on a second. Yep. Do you want me to control slides or do you want to
[00:13:15] Vasilis Kalos: It's fine if you can change the slides.
[00:13:21] Stanislav Smyshlyaev: Okay. Alright.
[00:13:24] Vasilis Kalos: Thank you. So hello, everyone. I'm Vasilis Kalos from Matter Labs. We'll give the first part of the presentations on BBS signatures. Next slide, please. Cool. So I will talk more on what is the status of the different documents that we have and what are the next steps, essentially. Next slide. So we have essentially three documents. There is right now, at least, there is the BBS signatures draft, which we will call BBS core here, and then we have various extensions. Right now, we have blind issuance and pseudonyms. Now
[00:14:21] Emil Lundberg: just
[00:14:21] Vasilis Kalos: a quick overview. BBS signatures are a multi message signature scheme that supports anonymous presentations and selected disclosures. So you can select or disclose subsets of messages to disclose, to the verifier, and the presentations are relinkable in the sense that our essential is your knowledge proofs of possession of the signature and the undisclosed messages. And an important property here to note is that unlinkability holds even, I guess, a quantum computer. So, you know, the scheme, the presentations are perfectly or statistically hiding, meaning that you as a presentation created today or presentation created today, if someone stores them, they will not be able to break the probability property later on using a Kovacan computer. Next slide. When it comes now to extensions, first of all, as I said, we have blood signatures, meaning that the user or the what we call approver will be able to commit to a set of messages to be included on the signature without the user knowing those messages. And when it comes to the status of blank signature, you will you will hear more about it later on. I will give a quick overview here. Essentially, what we are considering and what we are working on is implemented what we call committed disclosures. Commit disclosures are a mechanism that will allow you to easily extend BBS presentation with additional functionality and additional modules. And that's can this can be used for device binding, range proofs, revocation, pseudo names, which I will talk more about it a little bit later. And you will hear more about this commit disclosure mechanism later on the presentation as well. So next slide, please. Now when it comes to the status of the call, the call has been quite stable for some time now. We have already gone through one round of comments from the crypto panel, which we addressed. Now lately, have been working on two PRs, and those PRs are meant to address some comments we've gotten from some implementers. Now those are small changes, and what we try to do is the feedback we got from the implementers of the core draft is that, essentially, it's not that easy to create straight line implementation. So if you just want the core functionality without all the other extensions, it's there are some redundant checks. There are some redundant functions that you need to implement, which it's not quite clear why those are needed. Now the issue with that is that we cannot really create a completely straight line implementation of the draft because the cost scheme, one of the main use cases, is to support what we call anonymous credential systems. And those systems require more than just the issuance and presentation functionality. So as we said, you may need blind signatures, device binding, range, screws, revocation, and so So we are kind of forced to have quite a bit of modularity into the core draft so we can allow for those extensions. Now these PRs, although they don't completely solve that problem, they are there to make it easier if someone just wants a straight line implementation of just the core, make it easier for them to create that implementation. So they are there, first of all, to make the document a little bit more readable and minimize the return on checks on input values as much as possible. And this is done through some small restructuring of the operations and then introducing an object notation for some of the intermediate value of those functions and a function and operation that runs some validity checks of that object. So it's moving some of this redundant checks around into specific places. So it will be easier, first of all, And then if you want a straight line implementation without all the extendability, it's easier to describe call dispatch from that place. You don't need it to call that to call it in that place and so on. So when it comes to call, one question we have at the place that we will need some we'll appreciate guidance from the checks is essentially what are the next steps. Let's say that we finalize those PRs, and this will happen, you know, within the next couple of weeks, and we publish a new draft, what should we do next? Should we ask again on the list, for example, for another route of reviews from the crypto panel? Next slide, please. Now the other draft we have is pseudonyms. And I don't really want to take too much time to talk about it, but really quickly, essentially, pseudonyms have two flavors. The first flavor will allow you to create what we call a pseudonyms identity. Essentially, it's a value that it is is binded to your signature, to your credential, and it is constant within context but unlinkable, know, across different contexts. And there are two options to implement that. There is option a and option b here. And the other flavor of pseudo memes is that the pseudo mem value, it's not constant within that context, so it cannot be used to identify you in that specific context. However, it can be you can prove that you have not presented that pseudonym more than a predefined number of times within that context. So this is something that it is very much targeted for to rate limiting applications. So when it comes to pseudonyms, right now, we implement the second option that is for pseudonymous identity. The third option is specified in some other drafts. And the discussion now is in what options should we go? What should we describe on the document? And should we match the two documents together, the blank signatures and the pseudonyms to create one document with BBS extensions? And how what is the best way to start with pseudonyms as an application of this committed disclosure mechanism that I mentioned previously that is meant to bridge the BBS presentations with all the other functionality that we may want, like, you know, pseudo device button and so on. And next slide. So with this, I will pass the floor to Emil for the next part of the presentation. Thank you.
[00:22:29] Emil Lundberg: Thank you, Vasilis. Well, I am Emil from Yubico. And, yeah, one thing we unfortunately cannot do with the blind BBS draft as it currently is, is native device binding. And we call it native in contrast to explicit device binding, which will be the topic of the next presentation. But this is native the native variant is where you use the native algebra and curve where you already have the BBS proof, so it's more performant. And it sort of builds upon blind commitments, namely that if you commit to a public key, then you would have to prove possession of the private key during proof presentation. But that doesn't quite work for hardware bound private keys because the challenge that you need to sign in the BBS proof depends on all of the random nonces for all of the message scalars and the proofs. And the hardware signer cannot reveal its nonce because that leaks the private key. So you need to do a kind of two step process here. But what you can do instead, which is shown by this paper by Anja Lehmann and her colleagues, titled Device Bound Anonymous Credentials Without Trusted Hardware, or DBAC, what they show is you can instead prove a blinding relationship as part of the BBS message proof and then separately prove possession of the blinded public key. And that those two proofs in combination prove that you are in possession of the committed private key. So this needs some changes. Oh, formatting is a bit off. But, yeah, this needs some changes to the BlindBBS draft. And here's a summary of what those are. And there are three overarching themes. We need generators for the key binding attributes. You need to split the commitment phase into initialize, then prove, and then finalize steps so that you can take the challenge from the initializing step and then produce the key binding proofs to to share with the signer and then finalize to assemble all those proofs into one thing to send to the signer. And then, of course, the signer side needs the appropriate matching updates to the verification to to adjust for those additions. And then similarly for the proof generation, we need to split it into three steps. Initialize to generate the challenges, prove step to sign over the challenge with each of the binding keys, and then assemble the proof. One nice thing is that we can continue to use the core BBS ProofInit, ProofVerify, and ProofFinalize functions, just as they are without any changes. We do need to override the core verify function from core BBS because that one requires direct knowledge of all the message scalars. And we don't have that for the harbor bond keys. So it's not a trivial change, but I think I personally think there are changes worth making because it makes the scheme so much more practically useful. And a couple of remarks for discussion and consideration are, first of all, I've been talking about multiple device binding keys here, about the DBAC paper and the security proof only models exactly one device binding key. And zero keys is easy because that's just basic BBS so that we know that's secure. But it turns out that it's essentially zero additional effort to implement one or more device binding keys. But we probably shouldn't do that without actually writing out the generalized security proof. So that's a topic for discussion. Would it be interesting to have support for multiple device binding keys? And should we spend the effort to investigate that? You kind of get it for free with a BLS variant, where you can just do key shard against signature aggregation natively in the BLS signature. But it's a thing to consider for the Schnorr variant of this. And the rest of the stuff on the slide are about these tiny little implementation choices or protocol details that affect interoperability. And I'm not familiar with the landscape of existing implementations, but perhaps we should do some kind of survey of what are the existing implementations of Schnorr and BLS signatures out there, which of them can we even be compatible with, and which one should we be compatible with, and then make these choices of protocol details appropriately to to respect interoperability with existing implementations. And that's all for me. And next will be Anya talking about committed disclosure.
[00:26:53] Anja Lehmann: Alright. Can you hear
[00:26:56] Stanislav Smyshlyaev: Yep. Okay. We can.
[00:26:58] Anja Lehmann: Alright. Okay. Then please add to the next slide. Well, I wanna explain the the committed disclosure extension that we added to BlindBBS. And for that, it is kind of helpful to consider why we want to use BBS in in high level applications, and we are interested in using that, what's called anonymous credential systems. And that will require more functionality than what is currently covered with a core and blind BBS because that is focusing so far on selective attribute disclosure. Because he was not BBS is a multi message signature that signs different attributes, and currently, the the drafts allow you to either reveal or hide an attribute in the presentation. But when we wanna use it in anonymous credentials, we also wanna do other things with these attributes. As already said, maybe we wanna derive a pseudonym and prove it was correctly derived from a c that's in in the credential. You might not wanna reveal the date of birth, but rather prove it's over a certain age. Device finding could also be one in this explicit device finding where an attribute is actually device public key, and we wanna prove that we have access to the signing key. They also want other properties more on the on the core level, and different use cases will always require different combinations of these of these components and possibly even different instantiations because some of them are really optimal and proof sizes. Some have a certain legacy constraints. And the the challenge that we are kind of facing with these powerful primitives is how do we standardize them in a way that we can easily reuse them across use cases. So if you look at the next slide, there I try to kind of show at the at the top how we do it at the moment. So at the moment, we look at one particular use case. For instance, we have a credential that has an expiration date, a pseudonym seat, and the device public key in there, and then we have one use case at the target set, and we will write one standard that details all the subcomponents and also the Big zero knowledge proof, which means that whenever we have another use case, it also requires a range proof where you have to redo all the parts even though they overlap, which ends up in redoing a lot of work and might end up in a lot of redundant and not fully compatible standards and implementations. So our proposal here is to go for a modular framework that already defines and builds all the components in a in a way that makes it very easy to compose and plug and play with each other. And the core of it, and that now affects the BBS part, is a core module, which is a multi message signature, which BBS already is, and we just extend it to have this additional capability to have committed disclosures. So we can out output also attributes and commitments. And then all these extensions, pseudonyms, range proofs, device finding always work on committed inputs. And where this goes beyond what has been done over many years already in the literature or also in Edomix, we have done that quite some of the at IBM, is that we also say, let's just even down do the entire zonal knowledge proof per module. So really everything is defined per module, the only thing that we need to glue together is the commitment. Okay. So if we go to the next slide, please. There we see what it means for the core BBS part. So we added that, to the blind BBS track even though I think initially it was about blind issuance, and now this is about partially blind presentations. But the committed disclosure extension can be working both on blind BBS and core BBS because it just considers we have a signature on several attributes signed by an issuer key. And when making presentations, we can now not no longer just decide between hidden or revealed, but we have this new category which says it's a committed attribute. And then for these committed attributes, we also output a Peterson commitment and extend the zero knowledge proof very easily with a a quality proof that the commitment is really containing the attribute that was signed by the EBS credential. And then for the approved commitments and related attributes is public output, and the opening is what we have to give to the other modules together with the commitment so that they can do the bridging. Then to the next slide, please. So this is basically okay. That's all broken in design. But I was basically saying showing what we have to change. It's really minimal. Peterson commitments, equality proofs are really well known, and this is already used in the context of the EUDI wallet. So there's a technical specification, t s 14, which describes how we cannot use multi message signatures and BBS concretely to build a privacy preserving wallet. And that already uses the committed disclosure concept, and there's some ongoing ETSI standardization that is building upon that. We will also need extension modules. In the next talk, we talk about how to extend it with device finding for ECGS signatures. For range proofs, we hope we can just copy and paste whatever was done in the privacy pass working group pseudonyms we already have. We will also need a data format that is compatible with that modularity, and that was also proposed earlier that week by Christian Goerrmann. There should also be a link there in the Jose working group. So we already have several drafts that basically complement this core BBS so that we can fulfill the vision that we have. I'm trying to speak up on the next slide, please. I'm just saying that this is also helpful beyond EUDI. As I'm saying, privacy pass is also moving towards anonymous credentials, and I hope that, in particular, the extension modules, we can also use in other combinations and and use cases. About post quantum, Vasilis already said it's it's perfectly private, only soundness is discrete logarithm based, and I'm sure this is good enough for a lot of use cases such as online h verification where a quantum attacker is not really on the top list of our concerns at the moment. And the modularity also helps with crypto agility where we can move critical modules sooner to a post quantum variant than others. Okay. And in a matter of time, I think I'll just hand over to Vasilis if he wants to go for the next slide and summarize what we have done. We have one more summary. Yeah.
[00:32:40] Vasilis Kalos: Thank you, Anja. So, yeah, just to summarize where are we and what are the next steps. So in the core BBS, we have two open PRs that we are reporting right now. Those are really small changes that don't that only affect, really, the structure of the document. So, again, what are the next steps? Should we ask for a next round of review from the crypto panel after we publish or after we finalize those PRs. When it comes to pseudonyms, we need to decide on the approach. First of all, what to describe and then to decide if we want to merge it with the blind signatures draft and essentially make the blind signature draft. And it's really a BBS extension draft that describes the commitment disclosure mechanism and then device binding and pseudo names as associations with that mechanism. And finally, in for blind signatures, again, we now work on extending the functionality for modularity. We're working on describing the native device binding and pseudonyms in that draft, and then investigate more options for commitments for the committee disclosure functionality. So, you know, stuff with more compact proofs and so on. So that's it for the presentation. Thank you all very much. And if we have time, I will be happy to take questions.
[00:34:28] Stanislav Smyshlyaev: If there are any very quick questions. No? All right. And chairs will follow-up with editors about the questions being asked about various steps. Right, moving on. Anja, would you like to control slides yourself? Or
[00:35:11] Anja Lehmann: Yeah. If that's possible. Or Okay. Whatever is easier. Okay. So alright.
[00:35:23] Stanislav Smyshlyaev: You should have controls now.
[00:35:25] Anja Lehmann: Okay. Thanks. Yeah. So this is a presentation of a new draft proposal that we did together with Sofia, Shay, and Alexandros, and I'm presenting together with Shay. And that's about small type proof of possessions for ECDSA device binding. And I first wanna explain why we need device binding, and it's, again, kind of in the context of the EUDI Wallet. And there, we wanna use device binding to ensure what's called non transferability. Because if we have a digital identity credential kind of living on on user devices, in particular smartphones, we have to ensure that they cannot be easily compromised or shared across users. And the typical way to do that is to use device or hardware binding. So assuming that the user has a some secure element, some particular secure hardware device that can create cryptographic key material, and then we bind the user credentials to the device public key. Key. So the device public key is in a tested attribute in the in the credential. And then presenting the credential requires also proving that you have access to the corresponding hardware or the corresponding secret key, which is just a signature under the secret key over a session provided session on slide issue the verifier provides us. So that is a very classic way. That's also how it's done for the EUDI Wallet now. And the challenge is how we can do that device finding for anonymous credentials on the existing phones if we wanna deploy that now. That is a very critical requirement of the ID. I wanted so that we have this device finding if we wanna get anonymous credentials in there. And what is important to understand that in anonymous credentials, the device finding is very similar in in spirit than for classical credentials. So with anonymous credentials, we know we make a zero knowledge proof over the over the core credential, and now we also have to make a zero knowledge proof that we know the underlying device public key and that we have a proof of possession under it. And it's important that we hide the device public key because that otherwise would always be a highly unique identifier and which kind of contradict anonymous credentials that would reveal it. So the important thing is the zero knowledge proof has to be over everything. And what's also important to understand is that this we really have to deal with two different signature schemes here, issuer signature scheme and the device signature scheme for the device funding. And we have seen the presentation from Emil. If we have choice over the device signature scheme, we can do that natively, kind of very elegantly with the BLS or Schnorr signature. This would be running in milliseconds. Everything would be beautiful. But, unfortunately, life isn't beautiful. And we have to deal with this on devices today, and this is on the secure elements of the phones. This is just plain EC DSA. And this is not going to change because it's a secure element that you cannot easily extend with further cryptographic algorithms. The good thing is that once we kind of understand that we deal with two different signature scheme, we also realize that the friendliness matter kind of or it's it's very differently for the actual issue signature scheme, and we want to have a zero knowledge proof friendly scheme. Whereas for the device signature scheme, we actually can work around the limitation of e c t e c a okay ish because we don't need it to be as zero knowledge proof friendly as the main credentials. As I said, we don't have a choice for now. We have to work with EC DSA, and I think it's also okay in terms of post quantum migration because there, the the kind of the risk of a quantum attack or if a quantum attacker could break the EC DSA public key, the only thing it could do is to impersonate a single user. It can only break device binding. So at some point, we might wanna migrate the issuer signature scheme to post quantum, but it's still okay to use EC DSA. Probably, we don't have another choice if not everyone has a new phone. But that is I think it's okay because the risk is very, different. Okay. So we kind of look at this problem of how to do device binding for native anonymous credentials, but with EC DSA on the device. And we do that in this modular framework that we showed earlier, which allow us to kind of really focus only on the proof of possession module. We assume we get a d a committed public key, the EC DSA public key committed in a pairing friendly curve. We don't wanna compose it with VBS. Now we have to make a zero knowledge proof that we know a proof of possession under that committed key. And the advantage of this modular setting is that we can always choose the optimal signature, but also proof system per module. As I said, for the issuer signatures theme, if we wanna go for the most simple and and fastest way, this will be DBS signatures that we've just seen before over the Schnorf proof. For the device signature scheme, we don't have much choice anyway. It's going to be easy DSA if we wanna have it compatible with the existing phones. But then we still have flexibility in the proof system. The most conservative one that we are going for with this draft would be just use a Schnor proof as well. That already gives us kind of reasonable performance with below three hundred milliseconds on new phones and proof size of a 120 kilobyte. We also have a construction with bulletproofs that gives us very short proofs, which is, for instance, important if we wanna do proximity use cases. And, again, with the kind of modularity, we can easily plug and play as we go ahead. But for the draft and also for the UIDI model, we want to have something that's as simple as well understood and conservative as possible, and that's why we go with the Schnorr type version of CDSA signatures that is now presented by Shay.
[00:40:36] Shay: Hi, guys. Can you hear me?
[00:40:39] Anja Lehmann: Yeah.
[00:40:40] Shay: Okay. Anya, if you could just, take control of the slides, that would be great. So just a recap of the setting, we have a nonce that's, sent by a relying party, a device bound public key, and a signature from that key. And we wanna construct a zero knowledge proof of a valid signature on that key for the nonce. And we can't reveal the public key because we want unlinkability. On the left hand side, we have the standard ECDSA equation, which we rearrange to the form on the right hand side. And these two verification checks are equivalent, but the added benefit is that because the, nonce is public, we don't have to prove anything about evaluating the hash. This can be done publicly. And we also may reveal the value k, since it's used one time per signature and is therefore unlinkable. So the the value alpha can be computed in the clear. And then the remaining two elliptic curve points, Z, K, and Q, are committed to via the x and y coordinates. And since we're dealing with, p two five six, we have the base field of f q, and we construct a curve, t two five six or a Tom curve, which has, order equal to the base field of p two five six. So this allows us to commit to the coordinates of of elliptic curve points over p two five six. And this technique first appears in ZK-tests, but also appears in the follow-up work of CaDLs, which I'll introduce in the next slide, please. And, CaDLs is, introduces a proof of knowledge for this, which is sound and relies on standard, sigma protocol or Schnorr type technique, which has been around for over twenty years. And it's a composition of these two protocols below. So we've got a point edition proof, which takes the commitments to the x and y coordinates of three points and proves the, additive elliptic curve group operation on these points. And we have a protocol for scalar multiplication, takes a public base point k and the commitments to the x and y coordinates for some point r and proves knowledge of a discrete logarithm to of r to some, to the base k. And in the work, CLZ, which we base our draft on, we optimize the point addition and scalar multiplication proofs in CaDLs by about twenty five twenty five to 30% for proof of time, verification time, and signature size. Sorry. Sorry. Proof size. And, just a rough idea of how this composition works. So we prove that zed k is computed honestly using the scalar multiplication proof and then that the, the equation holds, via the point addition proof. And, yep. Next slide, please. And so just as a overview, at the beginning, we we had a t two five six commitment, but actually, coming out of the BBS credential, we we would we would be starting with the BLS commitments to the public key, which is non native. It's a different, scalar field. And so the first step of the of the overall, construction involves transferring a a proof a proof of knowledge that starts with a BLS commitment and shows us that, the t two five six commitments has opened to the same value, and then we can work over the t two five six commitments. And then we reduce the the ECTSA equation into proving the two sub claims, the scale of multiplication and point addition proof, and then prove these. This is done in the reduction of knowledge framework, which is a useful tool for, for composing interactive protocols. And this is how we follow, this process in the CLZ paper. Next slide, please. Okay. I'll hand over to Anya for the use cases.
[00:44:15] Anja Lehmann: Alright. So, also, just briefly kind of saying what I also mentioned in the previous talk. So this particular combination of using BBS as an issuer of signature scheme and EC DSA for device finding on user phones is considered in the EUDI Wallet and the technical specification t s 14, it's also part of an ongoing ETSI standardization. So, basically, this draft that we're proposing is can be used in combination with a blind BBS with committed disclosure draft I presented earlier, and we also have a data format that has already been done to align with core BBS and this ECTS a proof of position. So that's for the use case, and I'm kind of handing back to you, Shay.
[00:44:52] Shay: Yeah. So at the moment, our focus has been on the, robustness of the core cryptographic building blocks, namely the proof of the ECSA signature and the commitment transfer protocols. And we've also been considering integration with the Sigma protocol standard, although there are some things that are, not accounted for in that standard document as as it stands now, such as inequality checks for the verifier. And our next steps, which we would really welcome some support from the community with, are the precise specification of the complete noninteractive protocol with the, Fiat Shamir standard possibly, and serialization and data formats for the protocol as well as, the complete integration with all of the other BBS standards that exist now. And you can see our data track page via the QR code. I think we're ready to open up for questions. Thank you very much.
[00:45:49] Stanislav Smyshlyaev: Any comments, questions? Okay. Alright. Thank you very much. Okay. So actually, I have time.
[00:46:38] Anja Lehmann: Okay.
[00:46:49] Stanislav Smyshlyaev: Okay.
[00:46:58] Yumi Sakemi: Okay. Hi, everyone. I'm Yumi Sakemi from GM Connect Japan. Today, I will talk about short report about pairing friendly curves. Okay. Since the last presentation at ITF one two four, then we reported two things. The parameters were never the problem and the documents taught on scope about writing policy, not on content. After the meeting, we received the feedback. Yes. Please go ahead. So we decided to restart our activities. Since IT one two four, we achieved that we submitted the newest version of 13. In the newest version, we closed nine issues and 10 PRs. In the version 13, there are two substantive changes. One is about curve set, and the other is point serialization. First, the issue about curve set. We received a request that please change to parameter set to another other candidates. The candidates are shown below b n four four six, b r s two four five zero nine, and b r s forty eight five seven five. And then we reviewed the parameter set including candidates and our proposal parameters according to our selection policy in our draft. If you are interested in the detail of evaluation, please refer to issue 87. As a result, curve set is unchanged. Here, thank you for professor Alanha to his contribution in the evaluation. In addition, about one nine two bit security curves in our draft. This curve is not included in our draft and because there are no parameters that achieved the selection policy. And then we we asked that, do you want to one nine two bit security cards? And then we did not receive the no reaction at the period box. So there is not one nine two bit security curve in our draft. Second issue is about point serialization. The request is that adding adding the point serialization procedure to to note that normative parts. The background of this issue is MVBS, COSET, and BRS signature, they are used different point serialization. So we add the point serialization procedure in normative part in our draft. This slide shows the next steps we expected. In the current status, it has been through the crypt panel once in 2020. As expert reviewer have been reviewed our draft. And then we also resolved 40 comments in version zero five. And then is set ready for and open four days later. And now the parameters have not changed since. So we'd like to ask two things. One is for chairs. Could you start start second expert review? And since the parameters have not changed, review target is updated parts section five, appendix b d. And second is for shareholder members. We would like to close the 74 issues and 84 issues because we we solved it. But if you feel disagree or have some comments, please talk to me before r d rust call. This slide show the schedule. We'd like to report our Dirac call results to the next IETF meeting. That's all. Thank you for your attention.
[00:53:30] Stanislav Smyshlyaev: Any questions?
[00:53:36] Chairperson: Please.
[00:53:42] Emil Lundberg: Emil Lundberg from Ubico. Thank you very much for the work on this. And also, thank you for responding on the list to my comments earlier in the year. And I'm sorry for not replying to that. I did read the updated draft last night, and I appreciate the additions made to the pairing implementation guidance. I think that will help greatly with implementing this. I have not had time to try it yet, but I think that will greatly help. And I agree with the direction of the serialization and the deserialization functions. I did spot some I think there are some issues with the specification of the procedure, but I think those are just straightforward things that are obvious to fix. There are no decisions involved in fixing those. So I don't think that needs discussion to be fixed. Thank you very much for the work on this.
[00:54:39] Anja Lehmann: Thank you.
[00:54:40] Yumi Sakemi: Thank you very much.
[00:54:42] Chairperson: Yeah. To to recap, there's one or two minor tweaks, but thank you so much for all the additional work that you've done. And the chairs, unless there's any objection, will be moving this to crypto panel review. And we encourage the audience to comment on the two issues that the author that Yumi suggested here so that we can close them and move on to research group last call and unblock a bunch of different things. Thanks for all the work over the last few months with you and the coauthors of resolving this. It's very appreciated.
[00:55:19] Yumi Sakemi: Okay. Thank you very much.
[00:55:39] Stanislav Smyshlyaev: So with that, we have five minutes ahead of schedule. Any other business? Okay. I'm not, seeing anybody in the queue. Thank you very much for coming. Happy Friday, and happy almost the end of the ATF. Thanks, everyone. Thanks,
[00:56:24] Chairperson: Stanislav. Thanks, everybody.
[00:57:14] Stanislav Smyshlyaev: Yeah.