Open
Conversation
Member
|
I think something like this will make more sense when there's some level of baseline |
Contributor
Author
|
yea true. I'll leave this as WIP as it's required anyways for testing no-alloc impls and seeing what needs to get done. anyone wanting to join the effort can just PR my branch |
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
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.
Ref:
alloccore-only "heapless" support #51no_alloc-friendly keys #636MontyForm=>FixedMontyFormcrypto-bigint#1145HybridUintfor mix-matchUintin-struct crypto-bigint#1148In preparation for no-alloc RSA we would need gating alloc to default-on alloc feature.
Anyone using this in no_std context with default-features == false needs to add alloc feature given the current impl is alloc.
But on top if this we can start adding generic no-alloc impl without breaking the current alloc-dependant impl.
I could start trying with
FixedPrivateKeyetc. on next PR and then we can generalize actual algos around that and alloc one without breakage.Also need to add the alloc gating into crypto-primes and / or just avoid keygen for no-alloc to start.