Implement PKE

[tbraun96]

Performing key-exchange with Kyber is only half the story. Using the resulting keys to perform encryption/decryption of chosen plaintexts should also be a feature of this crate.

[mberry]

I would prefer to keep this repo focused on Kyber alone, certainly though it should be in the examples as a template for correct usage.

Have raised the point of creating a hybrid KEM api in #12, which on reflection should be a in separate crate, that perhaps is also a good place for including built-in encryption/decryption functions that use pluggable RustCrypto cipher traits.

Big fan of easy-to-use crypto, but separation of concerns takes precedence here.

[bwesterb]

This is what HPKE was designed for. We're working on getting Kyber into HPKE.

[ghost]

Hey, @tbraun96! It looks like you were able to implement this functionality independently? I stumbled upon it when looking for a way to handle CRYSTALS-Kyber encryption in Rust, and it seems your library is the most complete (it was honestly the only one I could find). I'm not the best at cryptography (hence why I'm not implementing the encryption myself...), so I was wondering if you feel your implementation is cryptographically sound. I will follow the recommendation to use Kyber in a "hybrid mode" of course, but I'm wondering if your implementation is fine or if I should just wait for a more established implementation to be developed.

edit: since Kyber establishes a shared symmetric secret, couldn't some flavour of AES be used for the actual encryption in a real-world scenario?

[bwesterb]

so I was wondering if you feel your implementation is cryptographically sound.

It's not: it uses the inner "indcpa" PKE which has malleable ciphertexts. Don't use it. Instead, use HPKE with full IND-CCA2 Kyber.

[ghost]

so I was wondering if you feel your implementation is cryptographically sound.

It's not: it uses the inner "indcpa" PKE which has malleable ciphertexts. Don't use it. Instead, use HPKE with full IND-CCA2 Kyber.

Thanks!

[tarcieri]

Hello, I'm writing on behalf of the @RustCrypto project.

We maintain the kem crate which provides an abstraction over KEMs: https://github.com/RustCrypto/traits/tree/master/kem

It would be interesting for this crate to implement those traits. See pqcrypto-compat as an example:

• https://github.com/rozbb/pqcrypto-compat
• https://docs.rs/pqcrypto-compat/latest/pqcrypto_compat/kem/kyber512/index.html

There's also this existing implementation of HPKE it should be possible to plug Kyber into: https://github.com/rozbb/rust-hpke

cc @rozbb

[bwesterb]

rust-hpke has support for Kyber (in a branch), see rozbb/rust-hpke#43

[mberry]

Hey Tony, certainly keen to add those KEM traits (#10) but was trying to avoid a GenericArray dependency, not particularly sure on the timeline for expanded const generics, there's a few of QoL improvements in this crate it would enable.

Would be happy with the traits behind a feature gate though.

[tarcieri]

@mberry our next release will get rid of generic-array, however unfortunately we can't fully migrate to const generics yet and are instead migrating to hybrid-array which at least has better const generic interop. Unfortunately we make use of associated size constants which don't yet interoperate with const generics.

Feature gating the functionality seems like a good way to avoid the extraneous dependencies.

[mberry]

HPKE is big scope and OOB for this project.

You can find a proposal on how to do this here: https://datatracker.ietf.org/doc/draft-westerbaan-cfrg-hpke-xyber768d00/

Closed for housekeeping reasons. Always happy to discuss it further though.