Skip to content

test: EC P-384/P-521#400

Open
pflynn-virtru wants to merge 2 commits intomainfrom
fix/3070-ec-p384-p521-xtest
Open

test: EC P-384/P-521#400
pflynn-virtru wants to merge 2 commits intomainfrom
fix/3070-ec-p384-p521-xtest

Conversation

@pflynn-virtru
Copy link
Member

@pflynn-virtru pflynn-virtru commented Feb 12, 2026

Summary

Adds integration tests reproducing opentdf/platform#3070 where EC P-384/P-521 decrypt (rewrap) fails because UncompressECPubKey hardcodes elliptic.P256() instead of using the passed curve parameter.

These tests are written TDD-style — they will fail against the unfixed platform with:

ecdh failure: ecdsa: invalid public key

Related platform PR: opentdf/platform#3071

What's included

Fixtures (xtest/fixtures/keys.py)

  • Shared helpers to reduce duplication:
    • _get_or_create_managed_key() — used by all managed key fixtures
    • _ensure_base_key() — used by all base key fixtures
  • New managed key fixtures:
    • managed_key_km1_ec384 — EC P-384 on km1
    • managed_key_km2_ec521 — EC P-521 on km2
  • New base key fixtures:
    • base_key_ec384 — EC P-384 base key on km1
    • base_key_ec521 — EC P-521 base key on km1
  • New attribute fixture:
    • attribute_allof_with_ec384_and_ec521_keys — ALL_OF attribute with P-384 (km1) + P-521 (km2) keys at attribute level

Tests (xtest/test_abac.py)

Test Use case Bug trigger
test_encrypt_decrypt_all_containers_with_base_key_ec_curve[P-384] Base key P-384, all containers (ztdf + ztdf-ecwrap) ztdf-ecwrap decrypt
test_encrypt_decrypt_all_containers_with_base_key_ec_curve[P-521] Base key P-521, all containers (ztdf + ztdf-ecwrap) ztdf-ecwrap decrypt
test_autoconfigure_key_management_ec384_ec521 Multi-KAS: P-384 (km1) + P-521 (km2) attribute-level keys Decrypt with both non-P-256 curves

Coverage matrix

Use case P-256 P-384 P-521
Base key + all containers test_..._base_key_e1 test_..._ec_curve[P-384] test_..._ec_curve[P-521]
Multi-KAS attribute-level test_..._two_kas_two_keys test_..._ec384_ec521 test_..._ec384_ec521
Cross-SDK interop all tests all tests all tests

Test plan

  • Verify tests fail against current (unfixed) platform with ecdh failure: ecdsa: invalid public key
  • Apply the one-line fix in lib/ocrypto/ec_key_pair.go (Curve: curve instead of Curve: elliptic.P256()) and verify all tests pass
  • Verify existing P-256 and RSA tests remain green (no regressions)

🤖 Generated with Claude Code

Add integration tests that reproduce opentdf/platform#3070 where
EC decrypt (rewrap) fails for P-384 and P-521 keys because
UncompressECPubKey hardcodes elliptic.P256().

Fixtures:
- managed_key_km2_ec_p384 / managed_key_km2_ec_p521: managed keys
- base_key_ec384 / base_key_ec521: base key configurations

Tests:
- test_encrypt_decrypt_with_base_key_ec384: encrypt/decrypt with P-384
- test_encrypt_decrypt_with_base_key_ec521: encrypt/decrypt with P-521

These tests will fail against the unfixed platform with:
  "ecdh failure: ecdsa: invalid public key"

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Paul Flynn <pflynn@virtru.com>
@pflynn-virtru pflynn-virtru changed the title test(xtest): add EC P-384/P-521 integration tests for issue #3070 feat: EC P-384/P-521 integration tests Feb 12, 2026
@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @pflynn-virtru, 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 introduces a set of integration tests designed to expose and validate a fix for a critical bug affecting Elliptic Curve P-384 and P-521 key decryption. By simulating the problematic scenario, these tests ensure that the platform correctly handles these cryptographic operations after the underlying issue is resolved, improving the robustness of the key management system.

Highlights

  • Integration Tests Added: New integration tests were introduced to reproduce and verify a known issue (EC P-384/P-521 ECDH failure: hardcoded P-256 curve in UncompressECPubKey platform#3070) where EC P-384/P-521 decrypt (rewrap) operations fail due to a hardcoded P-256 curve in UncompressECPubKey.
  • New Fixtures: Four new pytest fixtures have been added: managed_key_km2_ec_p384, managed_key_km2_ec_p521, base_key_ec384, and base_key_ec521. These fixtures facilitate the creation and management of EC P-384 and P-521 keys for testing purposes.
  • New Test Cases: Two new test cases, test_encrypt_decrypt_with_base_key_ec384 and test_encrypt_decrypt_with_base_key_ec521, were added. These tests create managed keys with the specified EC curves, set them as base keys, encrypt data using ec-wrap, and then attempt decryption to validate the fix for the identified bug.

🧠 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.

Changelog
  • xtest/fixtures/keys.py
    • Added new fixtures managed_key_km2_ec_p384 and managed_key_km2_ec_p521 for creating EC P-384 and P-521 managed keys.
    • Added new fixtures base_key_ec384 and base_key_ec521 for setting EC P-384 and P-521 keys as base keys.
  • xtest/test_abac.py
    • Added test_encrypt_decrypt_with_base_key_ec384 to test encryption and decryption with EC P-384 base keys.
    • Added test_encrypt_decrypt_with_base_key_ec521 to test encryption and decryption with EC P-521 base keys.
Activity
  • Integration tests were added to reproduce issue #3070, where EC P-384/P-521 decrypt operations fail.
  • The tests are expected to fail against the unfixed platform with an 'ecdh failure: ecdsa: invalid public key' error.
  • A related platform PR (test(ocrypto): add failing tests for EC P-384/P-521 ECDH bug platform#3071) addresses the root cause of the issue.
  • The test plan includes verifying test failures against the current platform and then verifying test passes after applying the one-line fix in lib/ocrypto/ec_key_pair.go.
Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces new fixtures and integration tests to address a critical bug related to EC P-384/P-521 key handling during decryption. The new tests effectively reproduce the reported issue and are well-documented. While the functionality is correct and addresses the bug, there is a significant amount of code duplication across the newly added fixtures and test cases. Refactoring these into more generic, parameterized functions or fixtures would greatly improve maintainability and readability. This is a common pattern in pytest, and applying it here would make future additions of similar key types much simpler.

@github-actions
Copy link

…ation

Address review feedback and broaden #3070 test coverage:
- Remove xfail markers (TDD: tests must fail visibly against unfixed platform)
- Parametrize base key test across all container types (ztdf + ztdf-ecwrap)
- Add multi-KAS test with P-384 (km1) + P-521 (km2) attribute-level assignment
- Extract _get_or_create_managed_key and _ensure_base_key shared helpers
- Remove unused managed_key_km2_ec_p384/p521 fixtures

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Paul Flynn <pflynn@virtru.com>
@sonarqubecloud
Copy link

@pflynn-virtru
Copy link
Member Author

/gemini review

@pflynn-virtru pflynn-virtru changed the title feat: EC P-384/P-521 integration tests test(xtest): EC P-384/P-521 integration tests for issue #3070 Feb 12, 2026
@pflynn-virtru pflynn-virtru changed the title test(xtest): EC P-384/P-521 integration tests for issue #3070 test: EC P-384/P-521 Feb 12, 2026
@pflynn-virtru pflynn-virtru marked this pull request as ready for review February 12, 2026 16:25
@pflynn-virtru pflynn-virtru requested review from a team as code owners February 12, 2026 16:25
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds integration tests for EC P-384 and P-521 curves, which is a great addition to reproduce and verify the fix for the reported issue. The refactoring to reduce code duplication in the test fixtures is well-executed and improves the maintainability of the test suite. I have one suggestion to make a test fixture more robust.

["p384", "p521"],
)
assert attr.values and len(attr.values) == 2
v384, v521 = attr.values
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The unpacking of attr.values assumes a specific order of the returned values, which might not be guaranteed by the underlying API. This could lead to brittle tests that fail if the order changes. Sorting the values before unpacking will make this more robust.

Suggested change
v384, v521 = attr.values
v384, v521 = sorted(attr.values, key=lambda v: v.value)

Copy link
Member

@dmihalcik-virtru dmihalcik-virtru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.



@pytest.fixture(scope="module")
def base_key_ec521(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd recommend against using base_keys for testing most things, since they are global tests that use them must be sequenced carefully

assert filecmp.cmp(pt_file, rt_file)


@pytest.mark.parametrize(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ooh I need to learn how to use parameterize properly. I've also been thinking about using subtests

@github-actions
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants