Imported ed25519 private key into fails to sign data using the vault secrets transit engine

[Ruddickmg]

Describe the bug
When I try to use a private ed25519 key that has been imported into vault it causes vault to produce a bad key length error for valid keys.

To Reproduce
Steps to reproduce the behavior:

1. Generate a private key (I have tried various methods, but this is a simple example)

   • openssl genpkey -algorithm Ed25519 -out private_key.der -outform DER

2. Import key into vault in any way (I have tried both the manual and the helper function methods)

   • vault transit import transit/keys/my-key "$(cat private_key.der | base64)" type="ed25519" derived=true
   • this step succeeds!

3. try to sign data with imported key

   • vault write transit/sign/my-key input="$(echo hello | base64)" context="$(echo world | base64)"

4. See error

Error writing data to transit/sign/my-key: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/transit/sign/my-key
Code: 500. Errors:

• 1 error occurred:
  • ed25519: bad private key length: 32

5. No logs relating to this error are output by vault, this is different than behavior in this issue, where we saw vault panic and show logs relating to the failure

Expected behavior

1. I would expect the data to be successfully signed with the imported ed25519 keys
2. If there was an issue with the key, I would expect the import step to fail (not the sign step)

Environment:

• Vault Server Version (retrieve with vault status): 1.20.4
• Vault CLI Version (retrieve with vault version): v1.20.4
• Server Operating System/Architecture:
  • linu x86 (ubuntu latest) running in docker v27.3.1
  • and arm7 (nixos latest) running in k3s v1.32.0,

Vault server configuration file(s):

for my local running in docker

listener "tcp" {
  address = "0.0.0.0:8200"
  tls_disable = true
}

for my remote server running on k3s

cluster_name = "vault-integrated-storage"
listener "tcp" {
  address = "[::]:8200"
  cluster_address = "[::]:8201"
  tls_cert_file = "/vault/userconfig/tls-server/tls.crt"
  tls_key_file = "/vault/userconfig/tls-server/tls.key"
}

seal "transit" {
  address = "https://vault-unseal.vault-unseal.svc.cluster.local:8200"
  disable_renewal = "false"
  key_name = "autounseal"
  mount_path = "transit/"
  tls_skip_verify = "false"
  tls_server_name = "vault-unseal"
  tls_ca_cert = "/vault/userconfig/tls-ca/ca.crt"
  tls_client_cert = "/vault/userconfig/tls-server/tls.crt"
  tls_client_key = "/vault/userconfig/tls-server/tls.key"
}

storage "raft" {
  path = "/vault/data"
  retry_join {
    leader_api_addr = "https://vault-0.vault-internal:8200"
    leader_ca_cert_file = "/vault/userconfig/tls-ca/ca.crt"
    leader_client_cert_file = "/vault/userconfig/tls-server/tls.crt"
    leader_client_key_file = "/vault/userconfig/tls-server/tls.key"
  }
  retry_join {
    leader_api_addr = "https://vault-1.vault-internal:8200"
    leader_ca_cert_file = "/vault/userconfig/tls-ca/ca.crt"
    leader_client_cert_file = "/vault/userconfig/tls-server/tls.crt"
    leader_client_key_file = "/vault/userconfig/tls-server/tls.key"
  }
  retry_join {
    leader_api_addr = "https://vault-2.vault-internal:8200"
    leader_ca_cert_file = "/vault/userconfig/tls-ca/ca.crt"
    leader_client_cert_file = "/vault/userconfig/tls-server/tls.crt"
    leader_client_key_file = "/vault/userconfig/tls-server/tls.key"
  }
  autopilot {
    server_stabilization_time = "10s"
    last_contact_threshold = "10s"
    min_quorum = 2
    cleanup_dead_servers = true
    dead_server_last_contact_threshold = "10m"
    max_trailing_logs = 500
    disable_upgrade_migration = false
  }
}

[VogonAnthology]

Same problem here, the reason is because the key derivation function (kdf, see "vault read transit/keys/:name") is set to "hmac-sha256-counter" for imported keys... When you create one (using "vault write transit/keys/:name"), it is set to "hkdf_sha256".

However, I didn't find a solution to change it to the right kdf... Please help !

[VogonAnthology]

The workaround I found is to change the file "sdk/helper/keysutil/lock_manager.go" :

func (lm *LockManager) ImportPolicy(ctx context.Context, req PolicyRequest, key []byte, rand io.Reader) error {

	//...


 // PREVIOUSLY ADDED CODE (after v1.20.4 release) ----- should already work as it is (to check) -------------------------

	if req.Derived {
		p.KDF = Kdf_hkdf_sha256
		if req.Convergent {
			p.ConvergentEncryption = true
			// As of version 3 we store the version within each key, so we
			// set to -1 to indicate that the value in the policy has no
			// meaning. We still, for backwards compatibility, fall back to
			// this value if the key doesn't have one, which means it will
			// only be -1 in the case where every key version is >= 3
			p.ConvergentVersion = -1
		}
	}

// END ------------------------------------------

	// START - ADDED CODE --------------------------------------------------------------------------------

	if p.Derived && p.Type == KeyType_ED25519 && p.KDF != Kdf_hkdf_sha256 {
		p.KDF = Kdf_hkdf_sha256
	}
       // END --------------------------------------------------------------------------------

	err = p.ImportPublicOrPrivate(ctx, req.Storage, key, req.IsPrivateKey, rand)
	if err != nil {
		return fmt.Errorf("error importing key: %s", err)
	}

	if lm.useCache {
		lm.cache.Store(req.Name, p)
	}

	return nil
}

This ensures that every imported ed25519 key uses the right kdf.

Unfortunately, I really won't to avoid having to fork that and use it instead of the vault release image...