-
Notifications
You must be signed in to change notification settings - Fork 568
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Abstraction Layer for Hybrid KEMs #4067
base: master
Are you sure you want to change the base?
Abstraction Layer for Hybrid KEMs #4067
Conversation
46d3084
to
9d9158d
Compare
9d9158d
to
f9ade5e
Compare
f9ade5e
to
3235a24
Compare
Rebased to master |
7548c0d
to
97b9ea2
Compare
Rebased to master. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some overly verbose iterator usage that I object to on aesthetic grounds :) but otherwise lgtm
std::all_of(m_sks.begin(), | ||
m_sks.end(), | ||
[](const auto& sk) { return sk->supports_operation(PublicKeyOperation::KeyEncapsulation); }), | ||
"Some provided secret key is not compatible with this hybrid wrapper"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here again a for
loop seems simpler and shorter
for(const auto* k: m_sks) {
BOTAN_ARG_CHECK(k != nullptr, "List of secret keys contains a nullptr");
BOTAN_ARG_CHECK(k->supports_operation(PublicKeyOperation::KeyEncapsulation), "Some provided secret key ...");
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What was a holding us back from ranges again? 😅 Was it Xcode/NDK again?
Thanks for the review. I agree that loops are easier to read here. It's quite sad that these C++ iterators are so bulky :( I addressed your review comments. |
I also made the KEX to KEM adapter header public. This is very useful for applications using non-predefined KEX algorithms with KEM combiners. Let me know what you think. |
21846e6
to
a35b674
Compare
a35b674
to
9252d58
Compare
Rebased to master |
a6828dc
to
f5d49e0
Compare
@randombit Sorry for the late update. I applied your review suggestions, rebased to master, and cleaned-up the history (to make it less bulky in the depending PRs). |
f5d49e0
to
2cbadce
Compare
We plan to add various KEM combiners in the following weeks/months. A KEM combiner is a KEM (with a KEM interface) that internally consists of two (or more) KEMs and/or key exchange algorithms transformed into KEMs. They are used for combining PQC with a classical public key algorithm. For that, this PR defines an abstract interface, a common base for these combiners.
In general, each KEM combiner consists of multiple public/private keys stored internally that are used to encapsulate multiple shared secrets. These multiple shared secrets are combined (using some sort of KDF) into a single shared secret. For that, the abstraction stores multiple public/private keys and implements the common boilerplate, such as defining the overall strength by returning the strength of the strongest sub-algorithm, etc. Also, a convenient interface for Encryptors and Decryptors is implemented. The existing TLS KEM combiner has been refactored to use this hybrid KEM abstraction.
For the BSI Project 481, we currently plan to implement the following three additional KEM combiners: