Add Post Quantum Cryptography

[russdm]

I found something quite interesting if you want to add Post Quantum Cryptography to dnscrypt-proxy.
It's quite new and in the prototyping stages. Ran a little experiment with the crypto library. If you add the mlkem folder as a sub folder in the crypto library. You can achieve X25519KEM768 handshakes with a hybrid post quantum key arrangement.

If you can get it to work with your current build add the additional crypto folder mlkem folder from the go crypto source.

https://cs.opensource.google/go/go/+/refs/tags/go1.24.2:src/crypto/

So far it works with with Firefox 137.0.2 and key exchanges as read in Wireshark are Client Hello Supported Groups: (0x11ec)
and Server hello key_share 4588. Which is X25519KEM768.

Just an idea.

It I can figure out how your processing the certificates it could be taken a step further to support full quantum safe algorithms, with certificates and keys.

[russdm]

For reference there's a lot of material to process. An additional feature for Linux liboqs and liboqs-go.

https://openquantumsafe.org/

Lot's to figure out, reach a cloudflare level of security.

[jedisct1]

With HTTPS, key exchange using MLKEM+X25519 can easily be achieved today by using a front-end to doh-server compiled with the current version of OpenSSL. Supporting both this and the AEGIS ciphers is just as straightforward.

On the dnscrypt-proxy side, I assume that as soon as the Go standard library supports these algorithms, dnscrypt-proxy will automatically support them as well.

Post-quantum DNSCrypt will require more work. A proof of concept was created a while ago using SIKE, but SIKE was unfortunately found to be broken.

Due to its small ciphertext size and its high security margin, Classic McEliece would make more sense than MLKEM for post-quantum DNSCrypt. However, its large public keys are not a good fit for distribution via DNS. The only reasonable solution would be to embed them in the stamp instead of the certificate.

Another problem is cost. This will require more CPU cycles than the current systems. As a user, you probably don't care. But as a volunteer running free DNS servers and paying for them out of my own pocket, I absolutely care — and so do all other similar DNS operators.

[russdm]

Any chance this wrapper is usable?

I'm trying to figure out how the private key and cert are processed for the local_doh and doh servers.

https://github.com/open-quantum-safe/liboqs-go

I tried a MLDSA44 key and certificate, and of course it failed miserably with:

FATAL ERROR tls: failed to parse key.

It's unclear in the code where this is processed, and which signature algorithm is chosen.

Just experimenting to see if it can be achieved.

[russdm]

I have the liboqs, and oqsprovider installed with openssl version 3.5.
Some of the default key signatures are now quantum safe.

[russdm]

Ok well by accident I achieved X25519MLKEM exchange with your current version of dnscrypt-proxy.

[russdm]

Works with cloudflare, and local_doh.

[russdm]

It would be interesting to also add a feature for encrypted client hello, would require an extra certificate.
Just wondering if that would be possible for testing under local_doh?