You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The Transit Export endpoint returns erroneous values for HMAC keys. For Vault-generated keys, the Export endpoint returns random 32-byte values (regardless of the requested key size). For imported keys, the Export endpoint returns a blank (empty) key.
AES keys return the expected value when imported + exported
HMAC keys that are created are the wrong length (always 32 bytes)
HMAC keys that are imported do not match the imported key
Expected behavior
Per the Gist above, I'd expect the exported key length to match the key_size parameter.
Also, I'd expect the exported HMAC key to match the imported key value. Output on my machine:
> Test create HMAC key of desired length:
Key length: 32, expected 64
> Test import HMAC key:
expected key: 3031323334353637383961626364656630313233343536373839616263646566
got:
> Test import AES key:
expected key: 3031323334353637383961626364656630313233343536373839616263646566
got: 3031323334353637383961626364656630313233343536373839616263646566
And directly querying the endpoints:
➜ vault read transit/export/hmac-key/hmac-test1
Key Value
--- -----
keys map[1:Z4DAJFsjCEVRgyjFFqjVcdrwvPhTuPLYiqqrUEFFK0U=]
name hmac-test1
type hmac
➜ vault read transit/export/hmac-key/hmac-test2
Key Value
--- -----
keys map[1:]
name hmac-test2
type hmac
Environment:
Vault Server Version (retrieve with vault status): 1.13.2
Vault CLI Version (retrieve with vault version): Vault v1.13.2 (b9b773f), built 2023-04-25T13:02:50Z (though this happens with github.com/hashicorp/vault-client-go v0.3.2)
Server Operating System/Architecture: MacOS (M1)
Vault server configuration file(s): N/A
Additional context
It looks like the Export endpoint is erroneously using the HMACKey "supplementary" key for hmac key types. This line should probably be returning key.Key rather than key.HMACKey:
@rzimmerman Ahhh this makes more sense after playing with the code a little more. I think we shouldn't have kept with separate HMACKey fields on the export. Notably, if you look at the backup, the
There's I think two bugs:
The shadowing of numBytes resulted in the decreased sizes you saw.
The use of an incorrect-and-random HMACKey value (that wasn't used for signing) caused the export discrepancies you saw as well: imported keys didn't get HMAC variants.
I've addressed both of these in #20864, but still need docs and tests for this :-)
Thank you for the detailed reproducer, it was very helpful!
Describe the bug
The Transit Export endpoint returns erroneous values for HMAC keys. For Vault-generated keys, the Export endpoint returns random 32-byte values (regardless of the requested key size). For imported keys, the Export endpoint returns a blank (empty) key.
To Reproduce
Steps to reproduce the behavior:
vault server -dev -dev-root-token-id root
Expected behavior
Per the Gist above, I'd expect the exported key length to match the
key_size
parameter.Also, I'd expect the exported HMAC key to match the imported key value. Output on my machine:
And directly querying the endpoints:
Environment:
vault status
): 1.13.2vault version
): Vault v1.13.2 (b9b773f), built 2023-04-25T13:02:50Z (though this happens with github.com/hashicorp/vault-client-go v0.3.2)Vault server configuration file(s): N/A
Additional context
It looks like the Export endpoint is erroneously using the
HMACKey
"supplementary" key forhmac
key types. This line should probably be returningkey.Key
rather thankey.HMACKey
:vault/builtin/logical/transit/path_export.go
Lines 164 to 165 in 1336abd
The text was updated successfully, but these errors were encountered: