feat(crypto): add NIST EC/ML-KEM hybrid key support#3275
feat(crypto): add NIST EC/ML-KEM hybrid key support#3275
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
bot
added
comp:db
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly expands the cryptographic capabilities by integrating NIST EC/ML-KEM and X-Wing hybrid key support. These changes enable the system to utilize advanced post-quantum safe key encapsulation mechanisms, affecting how data encryption keys are wrapped and unwrapped across the SDK and KAS components. The update includes new cryptographic implementations, schema definitions, and comprehensive test coverage to ensure robust and secure operation with these new key types. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. New keys now take their flight, Hybrid strength, a quantum shield, Data safe and bright. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request implements support for hybrid post-quantum cryptography (HPQC) algorithms, including X-Wing and NIST-based schemes, across the platform's crypto library, SDK, and KAS service. Key updates include the integration of the circl library, new hybrid wrapping logic for TDFs, and expanded algorithm support in the KAS registry. Review feedback identifies a critical type mismatch in the ocrypto library that prevents compilation, missing algorithm cases in legacy public key endpoints, and incomplete validation in protobuf definitions. Recommendations were also made to optimize slice concatenation and reduce redundant PEM parsing during decryption to improve performance.
| if block.Type == PEMBlockXWingPrivateKey { | ||
| return NewSaltedXWingDecryptor(block.Bytes, salt, info) | ||
| } | ||
| if params, ok := hybridParamsFromPrivatePEMType(block.Type); ok { | ||
| return newSaltedHybridECMLKEMDecryptor(params, block.Bytes, salt, info) | ||
| } |
There was a problem hiding this comment.
There is a type mismatch here. NewSaltedXWingDecryptor and newSaltedHybridECMLKEMDecryptor return pointers to specific decryptor types (e.g., *XWingDecryptor), but FromPrivatePEMWithSalt is declared to return an AsymDecryption struct. This will cause a compilation error. You likely need to wrap these decryptors in an AsymDecryption instance before returning.
| case security.AlgorithmRSA2048: | ||
| fallthrough | ||
| case "": | ||
| case security.AlgorithmRSA2048, security.AlgorithmHPQTXWing, "": |
There was a problem hiding this comment.
The LegacyPublicKey method is missing support for the newly added NIST hybrid algorithms (AlgorithmHPQTSecp256r1MLKEM768 and AlgorithmHPQTSecp384r1MLKEM1024). Only AlgorithmHPQTXWing was added to this case statement, which will cause requests for the other hybrid types to fail or return incorrect formats.
| case security.AlgorithmRSA2048, security.AlgorithmHPQTXWing, "": | |
| case security.AlgorithmRSA2048, security.AlgorithmHPQTXWing, security.AlgorithmHPQTSecp256r1MLKEM768, security.AlgorithmHPQTSecp384r1MLKEM1024, "": |
| id: "key_algorithm_defined" | ||
| message: "The key_algorithm must be one of the defined values." | ||
| expression: "this in [0, 1, 2, 3, 4, 5]" // Allow unspecified and object.Algorithm values for currently supported RSA bit sizes and EC curve types | ||
| expression: "this in [0, 1, 2, 3, 4, 5, 6]" // Allow unspecified and object.Algorithm values for currently supported RSA bit sizes, EC curve types, and X-Wing |
There was a problem hiding this comment.
The validation expression for ListKeysRequest is incomplete. It should include the new hybrid algorithms (7 and 8) to allow filtering by these types, consistent with the updates made to CreateKeyRequest and RotateKeyRequest.
| expression: "this in [0, 1, 2, 3, 4, 5, 6]" // Allow unspecified and object.Algorithm values for currently supported RSA bit sizes, EC curve types, and X-Wing | |
| expression: "this in [0, 1, 2, 3, 4, 5, 6, 7, 8]" // Allow unspecified and object.Algorithm values for currently supported RSA bit sizes, EC curve types, and Hybrid types |
| return nil, fmt.Errorf("%s ML-KEM encapsulate failed: %w", params.name, err) | ||
| } | ||
|
|
||
| hybridSharedSecret := append(append(make([]byte, 0, len(ecSharedSecret)+len(mlkemSharedSecret)), ecSharedSecret...), mlkemSharedSecret...) |
There was a problem hiding this comment.
This slice concatenation is inefficient and difficult to read. Using make with the correct capacity and copy is clearer and avoids the double append call.
hybridSharedSecret := make([]byte, params.sharedKeySize)
copy(hybridSharedSecret, ecSharedSecret)
copy(hybridSharedSecret[len(ecSharedSecret):], mlkemSharedSecret)| func unwrapHybridCiphertext(algorithm, privateKeyPEM string, ciphertext []byte) ([]byte, error) { | ||
| switch algorithm { | ||
| case AlgorithmHPQTXWing: | ||
| privateKey, err := ocrypto.XWingPrivateKeyFromPem([]byte(privateKeyPEM)) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("failed to parse X-Wing private key: %w", err) | ||
| } | ||
| rawKey, err := ocrypto.XWingUnwrapDEK(privateKey, ciphertext) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("failed to decrypt with X-Wing: %w", err) | ||
| } | ||
| return rawKey, nil | ||
| case AlgorithmHPQTSecp256r1MLKEM768: | ||
| privateKey, err := ocrypto.P256MLKEM768PrivateKeyFromPem([]byte(privateKeyPEM)) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("failed to parse SecP256r1/ML-KEM-768 private key: %w", err) | ||
| } | ||
| rawKey, err := ocrypto.P256MLKEM768UnwrapDEK(privateKey, ciphertext) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("failed to decrypt with SecP256r1/ML-KEM-768: %w", err) | ||
| } | ||
| return rawKey, nil | ||
| case AlgorithmHPQTSecp384r1MLKEM1024: | ||
| privateKey, err := ocrypto.P384MLKEM1024PrivateKeyFromPem([]byte(privateKeyPEM)) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("failed to parse SecP384r1/ML-KEM-1024 private key: %w", err) | ||
| } | ||
| rawKey, err := ocrypto.P384MLKEM1024UnwrapDEK(privateKey, ciphertext) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("failed to decrypt with SecP384r1/ML-KEM-1024: %w", err) | ||
| } | ||
| return rawKey, nil | ||
| default: | ||
| return nil, fmt.Errorf("unsupported hybrid algorithm [%s]", algorithm) | ||
| } | ||
| } |
There was a problem hiding this comment.
The unwrapHybridCiphertext function parses the private key PEM on every decryption call. This is computationally expensive. It would be much more efficient to parse the PEM once during loadKey and store the resulting decryptor object in the StandardHybridCrypto struct.
1 participant
Proposed Changes
Checklist
Testing Instructions