liboqs VS Bouncy Castle

How about liboqs from OpenQuantumSafe? It includes an implementation of most PQC primitives proposed to date:

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

Part of the issue as a prospective cryptographic user/consumer is that not only do I not know which algorithm(s) should be used, the most likely library https://github.com/open-quantum-safe/liboqs also explicitly states that it shouldn't be used in production.

Hybrid deployment (E.G. with ECC using a curve like 25519) is a great recommendation and probably obvious, far more so than picking a winner among the available post quantum possibly safe algorithms.

Hi everyone! I am currently trying to modify some settings within OpenSSL. My goal is to change the default algorithms that OpenSSL uses for generating certificates and signatures, as well as the key exchange method. Specifically, I want OpenSSL to default to the ones provided by OQS (https://openquantumsafe.org/), Dilithium and Kyber.

NIST - https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization

NSA - https://www.tomshardware.com/news/us-national-security-agency-issues-update-on-crypto-resistant-encryption

ISARA - https://www.isara.com/products/isara-radiate.html

OQS (NIST reports on this) - https://openquantumsafe.org

MSFT - https://www.microsoft.com/en-us/research/project/post-quantum-tls

Wikipedia's take - https://en.wikipedia.org/wiki/Post-quantum_cryptography

Efforts: Open Quantum Safe project

One thing I will mention for "most secure" is that you could add a second layer of encryption based on liboqs which aims to be quantum resistant (mostly important for asymmetric algorithms, symmetric algorithms are already thought to be quantum resistant). We don't know if any of the quantum resistant algorithms are any good or not. They could all be broken, so only use them as a second layer on top of existing encryption schemes, but if you want "the best", then that's what I would do: use standard tools with the biggest variants of the algorithm and then put a layer of post-quantum crypto on top of it.

Note that there may be incompatibilities until NIST has published the final revisions. Some specifications are on Round 3 kyber, others are on FIPS 203.

This one will interoperate with Bouncy Castle as we both use FIPS 203 draft, but won't interoperate with OQS that is still on the Round 3 submission.

See also: https://github.com/bcgit/bc-java/issues/1578

The readme mentions a dependency on Bouncy Castle - note that BC already contains several Java-based PQC signature schemes, see https://doc.primekey.com/bouncycastle/interoperability#Inter... and https://github.com/bcgit/bc-java

The best official resources are probably the example classes in the bouncycastle repository. They give you a rough idea for how to use the API, although they are a bit minimal unfortunately. You can probably apply a lot of domain knowledge (what algorithms are good/bad) from openpgpjs too, although you'd have to find out how the respective method calls are called on the BC side.

Why? Bouncy Castle has all you need.

Cryptography? Use Java Cryptography Extensions and Java Secure Socket Extensions with Bouncy Castle

Recently there was a constant time enhancement in bouncy castle that added a comparison using indexOf instead of charAt. Fairly easy to overlook, although glaring in hindsight, if there are no negative tests covering the functionality.