AES-KWP Performance Improvements for Apple#129911
Merged
Merged
Conversation
Contributor
|
Tagging subscribers to this area: @bartonjs, @vcsjones, @dotnet/area-system-security |
Contributor
There was a problem hiding this comment.
Pull request overview
Improves the Apple-specific AES Key Wrap with Padding (RFC 5649) implementation by avoiding repeated per-block EncryptEcb/DecryptEcb setup costs, while keeping the base Aes virtual implementation behaviorally equivalent.
Changes:
- Refactors
Aeskey-wrap core logic to support injecting an ECB “transform” delegate (enabling reuse of a single ECB cipher across many block operations). - Adds an Apple
AesImplementationoverride for key wrap padded encrypt/decrypt that uses a singleAppleCCCryptorLiteinstance for the whole operation (reducing setup overhead and allocations).
Show a summary per file
| File | Description |
|---|---|
| src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/AesImplementation.Apple.cs | Adds Apple-specific EncryptKeyWrapPaddedCore/DecryptKeyWrapPaddedCore overrides that reuse a single ECB lite cipher across the full wrap/unwrap operation. |
| src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/Aes.cs | Introduces delegate-based helper overloads for RFC3394 wrap/unwrap so platform implementations can supply a fast ECB transform without changing the protected virtual surface behavior. |
Copilot's findings
- Files reviewed: 2/2 changed files
- Comments generated: 0
bartonjs
approved these changes
Jun 26, 2026
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.
This gives anywhere for a 5x to 10x performance improvement for AES-KWP on Apple and reduces allocations for any input larger than 8 bytes. That is expected to be the common use case, as wrapping even a small symmetric key like AES is going to be 16 bytes.
The general theme of the change is not using
EncryptEcbon our internalAesImplementation. Each invocation ofEncryptEcbcreates and tears down handles. We need to keep callingEncryptEcbin our base class implementation because itprotected virtualand we need to keep calling the virtual.The
sealed internalimplementation can fast-path this though by re-using a lite cipher for each invocation of ECB."Single block" inputs don't change and are basically noise and are within error.
For [1, 8] there is no performance change.
For (8, 512] the improvement is ~5x.
For (512..] the improvement is ~10x.
Allocations are significantly down. Previously the allocations linearly scaled with the input length. Now the allocations are constant regardless of the input size. For example, before this change a 4096 input allocated 221,192 bytes. It now allocates 72.
What about Windows? That will be a follow up PR.