Drop Kyber support

[dstebila]

With ML-KEM support now available in liboqs and also in other TLS implementations (open-quantum-safe/oqs-provider#561 (comment)), it's been suggested in open-quantum-safe/oqs-provider#561 (comment) that we drop Kyber support from liboqs and oqs-provider. Thoughts?

[dstebila]

In today's OQS status call, I suggested that we keep Kyber in the forthcoming liboqs 0.12.0 release, and then drop Kyber in 0.13.0. We would include a note in the 0.12.0 release notes warning that this is the last release with Kyber.

We also discussed the impact this has on oqs-provider, and specifically re-assigning TLS hybrid code-points to the reserved range (open-quantum-safe/oqs-provider#561). It seems convenient to do that re-assignment at the same time as dropping Kyber support.

[loganaden]

I would suggest against doing that. There are commercial products that need to keep compatibility with Kyber768 while at the same time offering ML-KEM 768 support. Clients who are still on Kyber 512/768/1024 need to be supported.

[baentsch]

There are commercial products that need to keep compatibility with Kyber768 while at the same time offering ML-KEM 768 support.

What products are those? Why is this relevant for liboqs?

There is a disclaimer recommending against commercial use of OQS -- partially exactly for the reason for OQS not having (or rather, not being able) to support outdated software for a long time -- and even for free: Commercial products may offer long term or legacy support. There's whole companies only alive because of (people paying for) legacy software but I don't see why volunteers should do such work instead of doing new things.

Clients who are still on Kyber 512/768/1024 need to be supported.

What clients are those? If those clients use OQS, can they be motivated to help OQS maintaining this algorithm family?

[koraa]

Hi @baentsch,

@loganaden is helping us with the migration to ML-KEM in Rosenpass (PQ security for WireGuard and a generic mutually authenticated kem-based key exchange).

Our interest is mainly not giving our users a frustrating experience when they update their Rosenpass implementations; very long term support of Kyber is not a goal and we think people should migrate to ML-KEM eventually.

We are an open source project too but I am happy to chat about figuring out how support Kyber for longer.

[koraa]

And to be a bit more specific here: We don't have commercial clients right now for whom migrating would be a major issue. We have users who we would like to avoid alienating. Rosenpass is currently primarily but not exclusively funded using research and development grants.

[dstebila]

Hi Karolin! Thanks for the feedback. Do you have a sense of what your timeline is for removal of Kyber support?

[koraa]

@dstebila Thank you for getting back! We would be targetting a transition period of a couple of years. Long enough for us to:

1. Make a release with the new version
2. Have distributions adopt the new release
3. Wait for a year or more to give everyone ample time to upgrade

It would be possible to shorten the transition period by relying on two versions of liboqs, one outdated, deprecated with Kyber.

[baentsch]

Hi @koraa -- great to get in touch and thanks for the background information. Always good to know actual users of liboqs (thanks for the link-up @loganaden !). Also, funnily enough you also seem to have received funding from the great NLNet team which also allowed me to buy some bread while working on oqs-provider a few years back.

This statement is good

very long term support of Kyber is not a goal

but this gives me the creeps:

We would be targetting a transition period of a couple of years

So, allow me to understand how you can provide support over such long periods of time?

Regarding the procedure: Did you integrate liboqs via a specific release/tag? If so, why can't Rosenpass simply retain that and let liboqs move on? No-one will notice Kyber being removed from liboqs "main" and new releases as Rosenpass will keep using that tag/release, until you do an ML-KEM-based release of Rosenpass (then fixed to some more current liboqs tag/release), right? Or do you have maintenance expectations towards liboqs (particularly old releases)? If so, which ones?

Finally, may I ask about the reason to not fully integrate PQC into wireguard itself? If I don't misunderstand the purpose of Rosenpass

Rosenpass is used to create post-quantum-secure VPNs.

wouldn't this be a more desirable medium-to-long term goal over a "couple of years transition period" (and continued maintenance) for Rosenpass? Also, I'd be curious to understand (been a researcher myself a long time ago) what's the conceptual advantage of Rosenpass compared to say a generic PQC-enhanced software stack like OpenVPN?

[dstebila]

Regarding the procedure: Did you integrate liboqs via a specific release/tag? If so, why can't Rosenpass simply retain that and let liboqs move on? No-one will notice Kyber being removed from liboqs "main" and new releases as Rosenpass will keep using that tag/release, until you do an ML-KEM-based release of Rosenpass (then fixed to some more current liboqs tag/release), right? Or do you have maintenance expectations towards liboqs (particularly old releases)? If so, which ones?

This seems suboptimal. While one could get Kyber from an old tag of liboqs, presumably it would be preferably to be using ML-KEM from more recent builds of liboqs as that implementation evolves/improves. I would imagine that using two copies of liboqs within the same binary is quite tricky.

[baentsch]

I would imagine that using two copies of liboqs within the same binary is quite tricky.

Why would you (well, rather @koraa) do that? There would be one release (binary?) of Rosenpass (v0.x) with Kyber (and the corresponding liboqs version) and another/separate/future one (v0.x++) with ML-KEM (exclusively) --with a separate liboqs version--, no? Or do you indeed want to run both algorithms at the same time?

@koraa: Can you please shed some more light on how you use (and intend to use) liboqs? For example, is your app statically or dynamically linked to liboqs? Also, do you use liboqs-rust or are you bypassing that language wrapper? If the latter, what requirements do you have towards that project?

[dstebila]

I would imagine that using two copies of liboqs within the same binary is quite tricky.

Why would you (well, rather @koraa) do that? There would be one release (binary?) of Rosenpass (v0.x) with Kyber (and the corresponding liboqs version) and another/separate/future one (v0.x++) with ML-KEM (exclusively) --with a separate liboqs version--, no? Or do you indeed want to run both algorithms at the same time?

Interoperability? A server would need to support old clients that are using Kyber and new clients using ML-KEM, and hence would need to have code for both algorithms simultaneously. Presumably the same for new clients that still want to be able to talk to old servers.

[koraa]

Hi @baentsch, hi @dstebila,

thank you for your responses and your insight.

This statement is good

very long term support of Kyber is not a goal

but this gives me the creeps:

We would be targetting a transition period of a couple of years

I am glad you are happy about our plans regarding Kyber, and I am sorry our intentions about deprecation strategies have affected you in this way.

So, allow me to understand how you can provide support over such long periods of time?

The short answer is: It is not clear that this is a goal that can be accomplished, but we try as best as we can. In the name of usable security, we are trying hard to avoid friction for our users.

Regarding the procedure: Did you integrate liboqs via a specific release/tag?

We are directly relying on oqs-sys:

oqs-sys = { version = "0.9.1", default-features = false, features = [
    'classic_mceliece',
    'kyber',
]}

If so, why can't Rosenpass simply retain that and let liboqs move on? No-one will notice Kyber being removed from liboqs "main" and new releases as Rosenpass will keep using that tag/release, until you do an ML-KEM-based release of Rosenpass (then fixed to some more current liboqs tag/release), right?

It is exactly as @dstebila said:

This seems suboptimal. While one could get Kyber from an old tag of liboqs, presumably it would be preferably to be using ML-KEM from more recent builds of liboqs as that implementation evolves/improves. I would imagine that using two copies of liboqs within the same binary is quite tricky.

Having two copies of liboqs can probably be done, but yes -- it would be tricky and brittle.

And @dstebila's second point covers our perspective regarding your follow-up question:

Why would you (well, rather @koraa) do that? There would be one release (binary?) of Rosenpass (v0.x) with Kyber (and the corresponding liboqs version) and another/separate/future one (v0.x++) with ML-KEM (exclusively) --with a separate liboqs version--, no? Or do you indeed want to run both algorithms at the same time?

Interoperability? A server would need to support old clients that are using Kyber and new clients using ML-KEM, and hence would need to have code for both algorithms simultaneously. Presumably the same for new clients that still want to be able to talk to old servers.

In a nutshell: Imagine you are using Arch Linux on your client and Debian on your server, and you run a system update on both; Debian will update to the newest Rosenpass version after years; Arch will be quick. By using a hard deprecation strategy, we are giving this particular user a hard time because they now have to install a package on either system from outside the normal package users.

I do not think Debian currently integrates Rosenpass, but Arch Linux does. There are a variety of reasons why versions might be out of sync on client and server.

Or do you have maintenance expectations towards liboqs (particularly old releases)? If so, which ones?

This question comes as a bit of a surprise for me. There is no expectation we place on liboqs other than the usual expectations of collegial cooperation between open-source projects working on the shared goal of a post-quantum transition. We certainly do not have the expectation of an explicit or implicit service-level agreement.

I do like to believe that we maintain close, mutually beneficial relationships with other members of the real-world cryptography community, and I certainly believe working together to come up with the best deprecation strategies for something like Kyber is in the interest of us all.

Nothing is written in stone, and we do not have all the wisdom. We haven't depracted intermediate versions of newly standardized cryptographic primitives before either, and so I think we are in this together to figure out the best path forward.

That said, Rosenpass is one of a probably small number of open-source post-quantum projects using liboqs that do have quite a few real-world users, so I think we might be a useful case study for you.

Finally, may I ask about the reason to not fully integrate PQC into wireguard itself? If I don't misunderstand the purpose of Rosenpass

This question seems a bit out of scope for this particular venue. I am happy to jump on an email thread and discuss the design of Rosenpass if you are interested.

My e-mail address is karo@rosenpass.eu.

Rosenpass is used to create post-quantum-secure VPNs.

wouldn't this be a more desirable medium-to-long term goal over a "couple of years transition period" (and continued maintenance) for Rosenpass

Could you rephrase that question? I do not think I understand.

Also, I'd be curious to understand (been a researcher myself a long time ago) what's the conceptual advantage of Rosenpass compared to say a generic PQC-enhanced software stack like OpenVPN?

I think this query too might better be answered in another channel. I am happy to discuss, and we could collaborate to write a blog post, so the answers may be beneficial to all.

Thank you for the stimulating discussion to both of you!

[dstebila]

Nothing is written in stone, and we do not have all the wisdom. We haven't depracted intermediate versions of newly standardized cryptographic primitives before either, and so I think we are in this together to figure out the best path forward.

That said, Rosenpass is one of a probably small number of open-source post-quantum projects using liboqs that do have quite a few real-world users, so I think we might be a useful case study for you.

Indeed, I think the information you've given us is very useful. We need to be more proactive in trying to understand who is using liboqs and what they want from the project, and your perspective is really helpful.

[baentsch]

I do like to believe that we maintain close, mutually beneficial relationships with other members of the real-world cryptography community, and I certainly believe working together to come up with the best deprecation strategies for something like Kyber is in the interest of us all.

Agreed. Well, a year ago I had agreed more and wouldn't have asked a single question but just supported you(r app). Now, however, there's corporate entities that have taken control of OQS, not providing incremental funding or staffing but just adding demands and creating expectations the few people contributing or maintaining have to fulfil (or, rather juggle with sensible expectations like yours), see e.g., this:

To address research, the PQCA project lifecycle policy was explicitly designed to support research implementations as well as production code, and we have both research tracks and production tracks for projects. This dual-track approach will let OQS and its contributors to be able to continue to be leaders in research as well as move towards production code

(which actually already is a toned-down version as per PQCA/TAC#42 (comment) : And that shows another issue: The technical contribution activity of the formerly two most active contributors, @dstebila and myself have come to a crawl trying to "reign in" or try to fulfil an increase in commerce-oriented marketing activity /expectation setting not backed by a commensurate increase in technical contributions/activity -- the opposite actually, as per the above).

Back to the issue: I agree that retaining support for all algorithms that OQS ever supported is ideal for consumers, no doubt. At the same time, the PQCA-driven "productization" pressure creates process demands like security issues handling that's not just adding work and responsibility -- but also multiplies this by the number of algorithms supported.

Therefore, apologies to @koraa for the questions above: They've all been borne of the wish to keep OQS maintainable for a longer period of time and any support by the community (incl. users) to do so would be gratefully welcome. The other questions I'll take to email as per your suggestion.

[koraa]

Indeed, I think the information you've given us is very useful. We need to be more proactive in trying to understand who is using liboqs and what they want from the project, and your perspective is really helpful.

@dstebila Please consider us as having issued a standing invitation to collaborate on discussions, provide input, or collaborate on gathering empirical input regarding this topic or similar topics of how to maintain or governs PQC projects in practice. We are also in the process of learning :)

Agreed. Well, a year ago I had agreed more and wouldn't have asked a single question but just supported you(r app). Now, however, there's corporate entities that have taken control of OQS, not providing incremental funding or staffing but just adding demands and creating expectations the few people contributing or maintaining have to fulfil (or, rather juggle with sensible expectations like yours), see e.g., this:

I hear your frustration. There is no comprehensive answer I can offer other than a general critique of capitalism.

Open-Source projects such as OQS or Rosenpass are becoming relevant in the real world; one aspect of this is interest from companies, and companies are always interested in getting the most and giving the least. It's not a symbiotic relationship; it's a parasitic one.

When I began Rosenpass and when I decided to utilize a permissive FOSS license, I did so expecting and knowing that companies would exploit my work and that they would not give back appropriately. I can name concrete instances where that did happen.

The only advice I can give is that freedom from such exploitation is not found in opposition to it; in fact, the act of opposing someone or something is always also an expression of the power those opposed have over you. This is part of the reason why I tend to ignore the exploitation unless it's actively harmful, and I have the means to do something against it.

Instead, I use the resources at our disposal as best I can; I manage some cash flows, make sure contributors at Rosenpass are getting paid, and I use our impact on companies to strengthen my negotiation position.

I can not act outside of a capitalist system, I can only try to serve my group as best as I can and represent our interests.

Back to the issue: I agree that retaining support for all algorithms that OQS ever supported is ideal for consumers, no doubt. At the same time, the PQCA-driven "productization" pressure creates process demands like security issues handling that's not just adding work and responsibility -- but also multiplies this by the number of algorithms supported.

This is an issue your community probably needs to discuss internally. I would just offer the following standpoint:

I would think actively about the customer; both the commercial customer who should pay their share and the community customer, who you are trying to serve. I would focus on the community customer and ignore the commercial one.

It is possible to use the financial interests of companies to your advantage and to cross finance work for the community, but it is extra work and not necessarily the sort of work you want to do.

Therefore, apologies to @koraa for the questions above: They've all been borne of the wish to keep OQS maintainable for a longer period of time and any support by the community (incl. users) to do so would be gratefully welcome. The other questions I'll take to email as per your suggestion.

No offense taken :)
These are important conversations to be had!
Thanks for your E-Mail, I'll respond shortly.