Make KEM abstract methods protected to allow external subclassing - #2290
Open
jmcrawford45 wants to merge 3186 commits into
Open
Make KEM abstract methods protected to allow external subclassing#2290jmcrawford45 wants to merge 3186 commits into
jmcrawford45 wants to merge 3186 commits into
Conversation
- including more kyber name cleanup
- remove Symmetric, make MLKemEngine immutable - avoid overproducing implicit-rejection data - reduce memory usage - "Kyber" cleanup
- unify MLKEM mappings using SpiUtil - restrict keys by parameter set where appropriate
- use with ML-KEM (ensures ".OID." aliases are registered)
- unify HQC mappings using SpiUtil - restrict keys by parameter set where appropriate
- unify NTRU mappings using SpiUtil
- unify NTRUPrime mappings using SpiUtil
Sm2 key exchange See merge request root/bc-java!125
- add test classes missing from AllTests list - fix roundtrip test that was sensitive to platform line endings - avoid building complex error strings before errors occur
- add length check in internalGenerateEncapsulated
- more iterations validation - more convertToDefiniteLength variants - destroy PBE SecretKey
moved Mayo OIDs to OQS values
Package-private abstract methods on KEM prevent users from implementing custom KEMs (e.g. XWing) outside the org.bouncycastle.crypto.hpke package, requiring them to place subclasses inside the BC package as a workaround. Promote all abstract methods on KEM from package-private to protected. Update DHKEM.getEncryptionSize() to match — it was the only remaining package-private override; all other DHKEM overrides were already public or protected. This is a source-compatible change: existing subclasses (DHKEM) that override with broader visibility (public/protected) are unaffected.
Contributor
|
I'm not sure if this is really a good idea, I think you may, understandably, be looking at the wrong class for the job - we've found a better way (I'll admit the term is always a bit relative...) of describing KEM's which also works with the JCE, including the new KEM API which has been backported to Java 17. Would you have a look at the XWing implementation in core/src/main/java/org/bouncycastle/pqc/crypto/xwing and let me know what you think? |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
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.
Package-private abstract methods on KEM prevent users from implementing custom KEMs (e.g. XWing) outside the org.bouncycastle.crypto.hpke package, requiring them to place subclasses inside the BC package as a workaround.
Promote all abstract methods on KEM from package-private to protected. Update DHKEM.getEncryptionSize() to match — it was the only remaining package-private override; all other DHKEM overrides were already public or protected.
This is a source-compatible change: existing subclasses (DHKEM) that override with broader visibility (public/protected) are unaffected.