liboqs VS prusti-dev

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.

> The overall goal would be to figure out classical error conditions like nill pointers deference.

> If I can figure out if a pointer will be nil in some execution branch, there is no reason why a computer cannot do the same.

Note, this is called flow-sensitive typing (also called type narrowing) and I think that typescript does it.

https://en.wikipedia.org/wiki/Flow-sensitive_typing

> I personally would see this as an human race level upgrades. Imagine feeding your code to a CI that spit back something like: "you will have a panic at line 156 when your input is > 4"

A model checker can do that!

See this

https://model-checking.github.io/kani/tutorial-kinds-of-fail...

Other techniques are also possible

https://github.com/viperproject/prusti-dev#quick-example

(Here I could link a lot of things, I just selected two Rust projects to illustrate)

This works better if you are able to provide contracts in your API that says which guarantees you provide. Alternatively, asserts are useful too.

You might be interested in the Prusti project, which statically checks for absence of reachable panics, overflows etc. It also allows user-defined specifications such as pre and post-conditions, loop body invariants, termination checking and so on.

https://github.com/viperproject/prusti-dev

This is called refinement types and prusti might be the project you saw.

But there's also a lot of exciting work around formal verification like Prusti.

prusti

Efforts: seL4, Project Everest, the Prossimo project of the ISRG, Let's Encrypt, and Prusti for the Rust language

Wow that sounds really cool! I'm not an expert but does that mean that one day you could implement dependend types or refinement types in Rust as a crate ? I currently only know of tools like: Flux Creusot Kani Prusti