Key Vault does not support elliptic curve `secp256k1` on Java 16+

[vcolin7]

Oracle stopped supporting some elliptic curves starting on Java 16 and one of those is secp256k1, which needs to be supported by Key Vault Key's CryptographyClient when running on local mode only, that is, not communicating with the Key Vault service to perform cryptographic operations.

Given that we are trying to transition from supporting Java 11 to Java 17 in the Azure SDK, we need to figure out a way to support cryptographic operations that use this algorithm.

Options for achieving this are:

• Using a third-party library
• Writing our own implementation
• Allowing users to pass their own Security Providers via method overloads. (Suggested in #25570 as well for different reasons).
• Shading the code that Oracle used for this and including it with the SDK

NOTE: Tests that fail due to this on Java 17 have been disabled for the time being.

[eliquinox]

any news on this?

[hhanquez]

any news ?

[pentiak]

Any chance of getting it addressed?

[VinceBCD]

Any news ?

[vcolin7]

Hi everyone, sorry for the lack of updates, we had a few other items ahead of this in our queue. I will start working on an alternative for our Java 16+ users soon. In the meantime, you can still create and use keys with elliptic curve secp256k1 by using the Cryptography clients in default mode, that is, letting the client delegate these tasks to the Key Vault service as opposed to doing the operations locally.

[usmansaleem]

Hi @vcolin7 , are there any updates (or workaround) on this issue? Our code is failing on Java 17 as well.

 final CryptographyClient cryptoClient =
        vault.fetchKey(config.getKeyName(), config.getKeyVersion());

    final byte[] dataToSign = needsToHash ? Hash.sha3(data) : data;
    final SignResult result = cryptoClient.sign(signingAlgo, dataToSign);

java.lang.IllegalStateException: java.security.InvalidAlgorithmParameterException: Curve not supported: secp256k1 (1.3.132.0.10)
at com.azure.security.keyvault.keys.models.JsonWebKey.toEc(JsonWebKey.java:816) ~[azure-security-keyvault-keys-4.6.0.jar:4.6.0]
at com.azure.security.keyvault.keys.cryptography.EcKeyCryptographyClient.<init>(EcKeyCryptographyClient.java:49) ~[azure-security-keyvault-keys-4.6.0.jar:4.6.0]

How do you switch CryptographyClient from local mode to default mode?

[pentiak]

@usmansaleem, looking at your mention, have you confirmed that both local and default(remote) signing modes do not work on newer JREs?

[usmansaleem]

@pentiak our code is constructing CryptographyClient is follows:

    return new CryptographyClientBuilder()
        .credential(tokenCredential)
        .keyIdentifier(keyId)
        .buildClient();

The exception is raised when we perform cryptoClient.sign(...) operation. I am not 100% sure how to set local mode? The default mode definitely failed in Java 17 because it does not support SECP256K1 curve anymore (though BouncyCastle does). We need SECP256K1 because our code deals in signing for Eth1 private keys.

[pentiak]

I would really like this bug to be fixed. It is the only thing holding us back from upgrading JRE & Spring.

[hhanquez]

Please fix this bug ! Or at least answer to this question !

How do you switch CryptographyClient from local mode to default mode?

[vcolin7]

Hey folks, I'm sorry it took so long to address this. I just merged a change in PR #36657 to ensure the CryptographyClient goes back to use the service if it was not able to create a crypto client for local-only operation, which is the case when trying to use elliptic curve secp256k1 in Java 16+. We'll release this change in a new version in the next few days.

[github-actions[bot]]

Hi @vcolin7, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.