Key derivation and convergent encryption for ecdsa-p256

[sts]

Please add support for key derivation and convergent encryption for keys of type ecdsa-p256 to the transit backend as that would allow to handle Google Pay payment tokens via Hashicorp Vault.

Google uses ECIES-KEM, HKDFwithSHA256 and AES-256-CTR to encrypt its payment tokens which can be found in the documentation: https://developers.google.com/pay/api/web/guides/resources/payment-data-cryptography#payment-method-token-structure

Vault already supports key derivation for ed25519 as of PR #2778 so it would be great if the functionality could be extended to ECDSA-P256 keys.

Currently generation returns an error:

vault write transit/keys/googlepay convergent_encryption=true \
   derived=true kdf=hkdf_sha256 type=ecdsa-p256

Error writing data to transit/keys/googlepay: Error making API request.
URL: PUT http://localhost:8200/v1/transit/keys/googlepay
Code: 500. Errors:
* 1 error occurred:
    * key derivation and convergent encryption not supported for keys of type ecdsa-p256

Key derivation works with ed25519 and returns different results based upon context (btw. key derivation is currently not fully documented such as the kdf paramenter):

vault write transit/keys/googlepay convergent_encryption=true \
   derived=true kdf=hkdf_sha256 type=ed25519
Success! Data written to: transit/keys/googlepay

vault read transit/keys/googlepay \
    context=$(base64 <<< "googlex")  nonce=$(base64 <<< "123") -format=json \
    | jq '.data.keys[] '
{
  "creation_time": "2020-04-28T09:37:28.145966+02:00",
  "name": "ed25519",
  "public_key": "qokWRQTqNAJmNqGat09yczn0t2Jq8ELe2zfKoet1mhI="
}

vault read transit/keys/googlepayx \
    context=$(base64 <<< "google")  nonce=$(base64 <<< "123") -format=json \
    | jq '.data.keys[] '
{
  "creation_time": "2020-04-28T09:37:28.145966+02:00",
  "name": "ed25519",
  "public_key": "TvIZmCsQwe7AmBWN+pJXmNpmQffmsRvyoVl0syfeYw4="
}

[aphorise]

I believe that this is still applicable and would require implementation - not sure if this is the related area in the code.

Hey @cipherboy do you know if this is expected in any future release?

[cipherboy]

@aphorise Probably best to bring this one through PM if there's customer asks. We don't have immediate plans for this one.

I think the wildcard for me is if this is generally useful outside of its payment stuff or what, and how much work it'd be to support everything necessary from Transit's side. Notably, we don't support AES-256-CTR mode either, but its not clear if we need to either.

So I think it needs to be better scoped internally before we work on it.

[reinkrul]

You see more and more applications of elliptic curve cryptography (smaller key size, improved strength), so encryption support for it in Vault would be great. At https://github.com/nuts-foundation/nuts-node we use ECIES, but we can only support Vault as a more secure KV-store since it lacks support for it (ECIES). Would be great if it were supported, for more secure cryptographic operations (now we have to load the private key into application memory).