Make the error and http code clearer when supplying wrong unseal key

[nsimons]

The error message inspection is the same as used elsewhere in the code (vault/barrier_aes_gcm.go).
ErrInvalidKey is already handled as a http 400 response in http/sys_seal.go, so we can simply use it in vault/seal.go to get http 400.

Regarding the error message, omitting the "message authentication failed" part, as it is printed to the end user.

Fixes #17792

[hashicorp-cla]

All committers have signed the CLA.

[hghaf099]

@nsimons Thanks for submitting this PR. Copying my response from the linked issue:
I just checked the response error code going back to Vault 1.8, and we have always returned 500 error code if the unseal key is a properly b64 encoded key, however, it is invalid. On the other hand, providing an improper key, like unseal-key=1, to the unseal API will return the following though:

Error unsealing: Error making API request.

URL: PUT http://localhost:8200/v1/sys/unseal
Code: 400. Errors:

* 'key' must be a valid hex or base64 string

Note that changing this now would be considered backwards incompatible. I am going to close this ticket for now. Please reopen this issue or open a new one for further discussions.

[hghaf099]

@nsimons Thanks for contributing to Vault. We discussed the issue internally, and we would like to get the issue fixed. Would you please add a test (preferably a table test) to iterate through various cases to make sure the unseal behaviour is consistent? It would be good to see the same error code for all cases.

[nsimons]

Thanks for the guidance! Table test added, with some unseal cases. Is this more or less what you were after?

The test uses single key shard threshold so that we get the errors out. With higher threshold the invalid keys are quite often "blindly" accepted (HTTP 200) and the unseal mechanism waits for next key shard. But I guess this is by design.

Found one other return branch where it would make sense to have HTTP 400. The case is where key length is within the correct range, but the underlying AES cipher requires the length to be even. Two of the test cases tests for uneven byte length.

[hghaf099]

Thanks for working on this issue.
A couple of additional tests would be good to be added. One is testing at least another seal type. Second, testing unseal having multipart keys. I was able to trigger a couple of 500 error codes which were returned from here and here. The latter was found while configuring GCP seal, and unsealing with valid unseal keys from another cluster.

[nsimons]

Thanks! I added test cases for multi key-shards and AutoUnseal seal config. The two code locations that you found are hit by those test cases.

[raskchanky]

Looks good! Thanks for the contribution @nsimons