PQ security via kyber

[dartdart26]

Hey, I see that libOTe has kyber support. Do you think it is doable in CryProt too? I can take a stab at it, unless I miss something.

[robinhundt]

Hi, that's a cool idea! I think you mean the MR_KYBER protocol in libOTe which uses Kyber in the [MR19] protocol?

I don't have a lot of experience with PQ Crypto and haven't looked at the MR19 OT yet, but it would be nice to have a PQ secure base OT.

One issue is, that at the moment, there is no way of specifying the base OT protocol to use for the OT extension protocols. They simply use an instance of the Simplest OT. Some options I see:

• Add a generic parameter for the base OT protocol
• Switch to MR19 with Kyber (or probably ML-KEM ?) based on a feature flag
• Remove simplest OT and just have MR19 with a runtime configuration option that switches between DDH and Kyber

I'd rather not add a generic parameter for the base OT as I want to keep the API somewhat simple. I'll have to look into MR19 to make an informed decision.

But in any case, you could start implementing the MR19 protocol with PQ security and we later decide how to integrate that with the extension protocols. If the protocol implements the RotSender and -Receiver traits, that shouldn't be an issue.

[dartdart26]

Thanks for replying!

I have some version of it via a feature flag that just replaces Simplest OT, but was busy with other stuff these days. I am getting back to it soon and will post once I have something!

I experimented with ML-KEM from here: https://crates.io/crates/ml-kem

Maybe that's actually better, wdyt? Or it has to be compatible with libOTe?

[robinhundt]

If using ml-kem, that crate by the RustCrypto folks seems like the best option.

I'm not that familiar with Kyber and ML-KEM and have only skimmed some posts by Daniel Bernstein on potential issues with the ML-KEM standardization. There are also refutations (and this) of some of the claims by other cryptographers.

Personally, I'd go with ML-KEM, as it is the one that is standardized and I expect enough competent people will have looked at the specification and any changes made by NIST. But this is more based on a gut feeling and not on an actual understanding of the schemes.

Although a lot of this code is based on libOTe, compatibility with it is not a goal, so it would be totally fine to use ML-KEM in that regard.

[dartdart26]

Hey, I came up with that: #48

Any comments are welcome!