I have added patches to opmsg to implement PQC during the transitioning phase. Adding PQC sounds easier than it actually is, as there are several (administrative) problems:
* So far, no PQC algo has been standartized. Everything is still floating and in progress.
* Several PQC open-source projects exist, such as OpenQuantumSafe which implement the candidate algos, but which recommend to not use their impl in production code.
* Some patches for OpenSSL 1.1.0 exist such as for NTRU, but only cover the 1.1 API which will soon be denounced.
* OpenSSL 3.0 on the rising, changing the ENGINE API in favor of "Providers", but I didn't see any PQC code in it.
* Big tech companies making their own PQC patches and tests for marketing reasons but these are not usable for opmsg as they only cover TLS handshakes for their own good.
Sounds to me like I could only bet on the wrong horse by making any decision.
Therefore, I decided to agnostically add PQC support by following recommendations of the BSI when migrating crypto to PQC for the time being. That means extending opmsg Brainkey Personas by a second type "brainkey2" which adds a symmetric salt in the ECDH Kex. This is transparent to the user. At the same time, I ban non-AEAD symmetric algorithms for future encrypts (decrypts still work for compat) and extend the coverage of the AEAD to the entire message, including the header. That means that the entire opmsg is not only integrity protected by the ECDSA signature, but also by the AES-GCM MAC. The PFS property and everything else stays the same. The new default calgo is now "aes256gcm".
I am sorry I had to kick bf, cast5 and ripemd160 from newly encrypted messages, but these algos are outdated anyway. It should still be possible to decrypt all previous messages, despite of ciphers and persona types.
I have to check how OpenSSL develops, as I want to keep compatibility with LibreSSL API. So I have to be careful when adding new symmetric ciphers with AEAD capability such as EVP_aria_256_gcm().
Posts
