Abstraction Layer for Hybrid KEMs #4067
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
reneme
reviewed
May 22, 2024
FAlbertDev
force-pushed
the
kem-combiner-abstraction
branch
from
46d3084
to
9d9158d
Compare
FAlbertDev
force-pushed
the
kem-combiner-abstraction
branch
from
9d9158d
to
f9ade5e
Compare
FAlbertDev
force-pushed
the
kem-combiner-abstraction
branch
from
f9ade5e
to
3235a24
Compare
|
Rebased to master |
FAlbertDev
force-pushed
the
kem-combiner-abstraction
branch
3 times, most recently
from
7548c0d
to
97b9ea2
Compare
|
Rebased to master. |
randombit
reviewed
Jun 15, 2024
| 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.
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.
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. |
FAlbertDev
force-pushed
the
kem-combiner-abstraction
branch
3 times, most recently
from
21846e6
to
a35b674
Compare
Open
FAlbertDev
force-pushed
the
kem-combiner-abstraction
branch
from
a35b674
to
9252d58
Compare
|
Rebased to master |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: