Right now, we support three different crypto providers: OpenSSL 1.1, OpenSSL 3, and BoringSSL. These providers have largely the same API, so we have a slightly hairy mess of #ifdefs to account for the differences. If we were to try to add support for CryptoKit, X-CUBE-CRYPTOLIB or liboqs, we would need things to look substantially different.
We should consider introducing a stronger interface/implementation separation, and segregating the implementation code according to the underlying crypto provider.
Prior art in mls-rs:
https://docs.rs/mls-rs/latest/mls_rs/trait.CryptoProvider.htmlhttps://docs.rs/mls-rs/latest/mls_rs/trait.CipherSuiteProvider.html
Overall concept:
lib/hpke/src has files for some set of providers- Non-goal to allow runtime addition of new providers
- Each instance of MLSpp is built for a single, specific provider
- Consumer selects provider with CMake flags
Right now, we support three different crypto providers: OpenSSL 1.1, OpenSSL 3, and BoringSSL. These providers have largely the same API, so we have a slightly hairy mess of
#ifdefs to account for the differences. If we were to try to add support for CryptoKit, X-CUBE-CRYPTOLIB or liboqs, we would need things to look substantially different.We should consider introducing a stronger interface/implementation separation, and segregating the implementation code according to the underlying crypto provider.
Prior art in
mls-rs:https://docs.rs/mls-rs/latest/mls_rs/trait.CryptoProvider.htmlhttps://docs.rs/mls-rs/latest/mls_rs/trait.CipherSuiteProvider.htmlOverall concept:
lib/hpke/srchas files for some set of providers