mirror of
https://github.com/unrealircd/unrealircd.git
synced 2026-07-01 13:26:38 +02:00
Bram Matthys
877d151da4
In the past a dual cert/key setup could have been useful for RSA + ECDSA but nowadays all clients support ECDSA so that makes little sense. The reason it is added now is so you can use ECDSA + ML-DSA or some other [regular crypto] + [post quantum crypto] combination. Actually, you could even use more than two. To use this in the config file, simply use the certificate and key directive multiple times. Just be sure to load the certificates and keys in the same order. We will print a helpful error if you fail to do so. Note that for Post Quantum Cryptography the most important step today was/is to protect against the "Harvest now, decrypt later" scenario https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later which is a "passive attack". That's why in UnrealIRCd 6.2.0 we enabled X25519MLKEM768 if it is available (OpenSSL 3.5.0 and later). While, this commit, and this talk about dual ECDSA and ML-DSA, is about when a quantum computer exists and actively does a man in the middle attack. That's not a realistic scenario in 2025 and according to experts also not in the next few years. We just make the UnrealIRCd code- base ready to have this feature for when it is needed / will be used, and to get this tested properly. For testing the dual ECDSA and ML-DSA setup I used the following command to create the 2nd cert/key (self-signed): openssl req -x509 -nodes -newkey mldsa65 \ -keyout ~/unrealircd/conf/tls/server.key.mdsa65.pem \ -out ~/unrealircd/conf/tls/server.cert.mdsa65.pem \ -days 3650 And then: listen { ip *; port 6697; options { tls; } tls-options { certificate "ssl/server.cert.pem"; key "ssl/server.key.pem"; certificate "ssl/server.cert.mdsa65.pem"; key "ssl/server.key.mdsa65.pem"; } } When running openssl s_client -connect 127.0.0.1:6697 it shows ML-DSA is used: ... Peer signature type: mldsa65 Negotiated TLS1.3 group: X25519MLKEM768 ... And with openssl s_client -connect 127.0.0.1:6697 -sigalgs "RSA+SHA256:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA384" it shows ECDSA is used: .. Peer signature type: ecdsa_secp384r1_sha384 Negotiated TLS1.3 group: X25519MLKEM768 .. This is just for testing purposes (self signed cert). As of right now (Sep 2025), you can not get a trusted certificate with ML-DSA, as the CA/Browser Forum only allows issueing RSA and ECDSA keys. Also, all the trusted Certificate Authorities use RSA or ECDSA. And, again, all this is not ML-DSA specific, it should work for other dual/multi combinations, and.. who knows they even go for something hybrid. A downside of dual certs is that this makes the whole spkifp thing more complicated because if you use 2 certs/keys you now have 2 possible fingerprints (spkifp) that could match in e.g. server linking. While coding this, I also changed the 'STATS P' output to use the txt numeric instead of notice, and be more verbose in its output for TLS listeners: printing the certificate(s) and key(s).