Questions about further development and PRs

[Muzosh]

Happy New Year!

I'm focusing on PQ migration from an engineer's point of view and I just got stuck on experimenting with PQ in Golang, in crypto/x509 package to be precise.

After some iterations of thinking how to PQ-ize existing applications written in Go using x509 package, I got into a stage where I would like to create my own crypto package fork. Then I remember "hey, Cloudflare already did something like that".

My goal is to have a Go source, that:

1. Has PQ-capable x509 package.
   • Here I'm talking mostly about ML-DSA or pure Dilithium algorithms
   • I see that hybrid modes are already implemented (PureEdDilithium?), but I would like to also do pure PQ
   • I see that ML-DSA is already implemented in CIRCL. Is this fork outdated?
2. PQ-TLS capabilities are good to have
   • I see that it is already implemented
3. Maybe some crypto-agility?
   • I started a discussion about crypto-agility in here and I may have ideas and motivation to make Go crypto package more

So I would like to lift off from this library and start working towards my goals. Before I do that, I want to ask what is the current stage or progress in development of this repository.

Is there someone already working on something listed in my goals? Would you be interested in reviewing and possibly accepting some PRs, that will implement:

1. Update CIRCL dependency to 1.5.0, thus enabling ML-DSA
2. Integrate more (non-hybrid, pure ML-DSA and Dilithium) algorithms into x509 and enable all functionality where the current official go/crypto/x509 fails with "Unsupported algorithm" error
3. Work towards more crypto-agile crypto library. For example, creating crypto.Verifier with method Verify (same as there is crypto.Signer) and all relevant crypto subpackages could accept this new interface instead of having hard-coded switch statements based on public key type.

Please note that the list of goals and possible PRs is not complete as I just started delving into PQ-capable Go recently.

Looking forward for you answers :)

[bwesterb]

Happy new year. Thanks for reaching out.

On encryption. Unless you really need it, in TLS, for key agreement I would stick to X25519MLKEM768 until key share prediction sees widespread adoption. For other use cases I'd advise X-Wing, although I'll add a caveat that industry hasn't really converged yet. The current proposal in the LAMPS working group of the IETF is very close to X-Wing, but not wire compatible.

For signatures LAMPS is close to standardising pure and hybrids are probably not very far away either. So I'd prefer not to have to redo everything once the standards are set.

One issue that can be tackled now, is how to solve the "unsupported algorithm" error. See also #183. It's not directly obvious what is the best way, but I have to add that I didn't sit down to think about it properly. If you have time to propose a solution I would love to hear it.

On crypto aligity: there is a lot of work in maintaining a fork. One priority for us is to keep the difference with upstream Go small. Now, there is a lot to say about crypto agility, but I wanted to mention a few points. First, CIRCL and upstream Go have different goals. CIRCL is meant to experiment and doesn't guarantee stability (even though we try not to break things too often). Upstream Go tries very hard not to break people while making good security choices for the user. It's easier to adapt to evolving security needs without breaking existing applications, if you give applications fewer levers. An extreme example: if Go doesn't allow the user to choose any algorithm, then it can upgrade all users to post-quantum without them having to do anything.

You touched on a lot, hope I didn't miss something I should've answered to.

[Muzosh]

Thank you Bas for answering. I believe you touched on every topic and gave me more topics to think about.

However, could you please elaborate what you mean by "So I'd prefer not to have to redo everything once the standards are set." when talking about signatures?

Are you talking about potential PR? I think I would be willing to work on this in the most LAMPS-compatible way as possible.

P.S.: I'm not saying "I will create PR and you will accept it" :) I started this conversation in order for me to determine my next course of actions and whether some of it would be helpful to this repo as well.

[bwesterb]

I think I would be willing to work on this in the most LAMPS-compatible way as possible.

Until it's an RFC, the IETF can change their mind on the finer wire format details in incompatible ways. (One example is the private key format. It's likely going to be a seed, but there is a non-zero chance that they'll revert to the expanded private key format.)