VMware ESXi and vSphere Cluster Management

Private Keys: Purpose, Security, and Practical Use

Learn what private keys do, how they work with public keys, and how to generate, store, back up, rotate, recover, and respond to private-key exposure.

A private key is secret cryptographic material used in asymmetric cryptography. It is the private member of a mathematically related key pair; the other member is a public key.

Anyone may usually receive a public key, but the private key must remain confidential. Possession of a private key generally proves control over actions associated with its public key, such as authenticating to an SSH account, signing software, decrypting information, or controlling a cryptocurrency wallet.

Private Keys and Public Keys

Asymmetric cryptography uses two related keys instead of one shared secret. A trusted cryptographic tool generates the pair. The public key can be distributed, registered, or placed in a certificate. The private key stays with its owner or inside a protected key-management system.

A private key is not a password, passphrase, API key, shared secret, or public key. A password is usually entered and checked by a service. A passphrase commonly protects a private-key file. A shared secret is known by both communicating parties. A public key is designed to be distributed. A private key is normally used by cryptographic software rather than typed into a service as ordinary text.

How Public-Key Cryptography Works

Key generation creates a public/private pair. Public-key derivation produces the public key from the private key or from related mathematical parameters. The public key does not provide a practical way to reconstruct the private key when a secure algorithm and adequate parameters are used.

• Encryption to a recipient: A sender uses the recipient's public key. The recipient uses the corresponding private key to decrypt or unwrap the protected data.
• Digital signature: The signer uses the private key to create a signature. Anyone with the public key can verify that the signature matches the data and key.
• Authentication: A claimant proves possession of the private key without transmitting the key itself.
• Key agreement: Parties combine private and public key material to derive a shared secret.

Modern systems usually do not encrypt large files or all network traffic directly with a private key. Public-key operations are comparatively expensive. Instead, a protocol commonly creates a random symmetric key, uses it for efficient bulk encryption, and uses public-key cryptography to establish or protect that session key.

Core Private-Key Operations

Do not assume every key can perform every operation. An encryption key, signing key, authentication key, and key-agreement key may use different algorithms, parameters, policies, and storage controls. Separating purposes limits the impact of one compromised key.

Digital signatures

Software commonly hashes the data first, then signs the hash with a private signing key. The recipient receives the data, signature, and trusted public key. Verification checks both that the data was not changed and that the signer controlled the corresponding private key at signing time.

SSH authentication

For SSH, generate the key pair locally. Install only the public key in the remote account's authorized_keys file. During login, the client proves possession of the private key through a challenge-response protocol; the server verifies the proof with the stored public key. The private key is not sent to the server.

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519_example -C "user@example.com"
chmod 600 ~/.ssh/id_ed25519_example
ssh-keygen -y -f ~/.ssh/id_ed25519_example
ssh-add ~/.ssh/id_ed25519_example

Protect the generated key with a strong passphrase. The final command loads an unlocked key into an SSH agent, which performs authentication operations on behalf of the user. An agent reduces repeated exposure of the key file, but the agent process and host still require protection.

Key-Pair Lifecycle

1. Generate: Use a trusted, updated cryptographic tool or a managed KMS/HSM. Select an algorithm and size supported by the application and policy.
2. Protect immediately: Apply a strong passphrase where appropriate, restrictive permissions, access controls, and hardware or managed protection when risk warrants it.
3. Derive and register: Distribute only the public key. Register it with SSH, a certificate authority, a source-control service, a wallet, or another intended system.
4. Use narrowly: Assign a unique key to each purpose, system, or security boundary where feasible.
5. Back up: Create encrypted, controlled backups when recovery is required. Document who can recover them and test recovery before an emergency.
6. Rotate: Replace keys on schedule, when personnel or systems change, or after suspected exposure.
7. Revoke and retire: Revoke certificates, remove SSH authorized keys, disable credentials, or migrate trust to the replacement key.
8. Destroy: Securely delete obsolete copies when retention requirements permit, including temporary exports and backup copies.

Formats, Containers, and Encodings

The algorithm describes the cryptographic method, such as RSA or an elliptic-curve algorithm. A container format describes how key information and metadata are organized. An encoding describes how those bytes are represented. A file extension such as .key or .pem is only a hint and does not reliably identify either one.

A private-key file may be encrypted at rest, but that does not change what the unlocked key can do. File encryption and cryptographic capability are separate concerns. Inspect formats cautiously and avoid commands that print secret contents. Never paste key material into a terminal transcript, support ticket, chat, repository, or log.

Algorithms and Key Strength

• RSA: A widely interoperable public-key algorithm. Use current approved sizes and padding schemes; avoid obsolete small keys and legacy settings.
• Elliptic-curve cryptography: Provides strong security with smaller key parameters than RSA in many applications.
• Ed25519: A modern elliptic-curve signature system commonly used for SSH and other signing tasks.
• ECDSA: An elliptic-curve signature algorithm used in some certificates and protocols.
• ECDH: An elliptic-curve key-agreement method used to derive shared secrets.

Algorithm choice depends on the application, supported libraries, interoperability requirements, compliance rules, and migration plans. Use modern supported algorithms and trusted defaults. File size, filename, or visual length does not by itself indicate key strength. Avoid deprecated algorithms, weak curves, undersized RSA keys, obsolete protocol options, and custom cryptography.

Storage and Protection

Use least privilege: limit which users, processes, hosts, and services can invoke a private key. Protect encryption at rest, use restrictive file ownership and permissions, review access policies, and enable audit logging. Do not email keys, embed them in application images, store them in plaintext configuration, or share one private key among many people and environments.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -aes-256-cbc -out private-key.pem

This example creates an encrypted PKCS#8-style PEM private-key file and prompts for its passphrase. Use application-approved algorithms and sizes; this command is not a universal policy. For a TLS service, use a dedicated service account or approved secret store. A typical file configuration is owner root or the service account, mode 600, and parent directories that do not permit unauthorized traversal or modification.

Backup, Recovery, and Key Loss

A lost private key may permanently prevent decryption of protected data, access to an identity, verification of a signing workflow, or control of a wallet. A public key cannot reconstruct its private counterpart.

For recoverable systems, store encrypted backups offline or in an approved protected vault. Keep the backup passphrase or recovery material through a separate approved mechanism, restrict access, define retention rules, and test restoration. Key escrow or managed recovery can help an organization recover encrypted data, but it introduces another high-value target and requires strict authorization and auditing.

Managed KMS keys may support recovery and controlled use without exporting raw key material. Non-custodial keys, such as some wallet keys, may have no provider recovery. One-time recovery-seed models require careful offline protection because anyone with the seed may control the associated assets.

Responding to Suspected Compromise

Indicators include a key appearing in a repository, email, chat, ticket, log, backup, or unauthorized host; unexpected authentication or signing activity; a lost device; or an unknown person gaining access to the key or its passphrase.

1. Stop using the suspected key.
2. Assess where it existed, who could access it, and what it protected.
3. Revoke certificates, remove authorized public keys, and disable related credentials.
4. Generate a replacement pair in a clean, trusted environment.
5. Deploy the replacement public key, certificate, or trust record.
6. Rotate affected passwords, API keys, session credentials, and other secrets.
7. Review access and audit records, preserve evidence, and document the incident.

Application Contexts

SSH and Git

An SSH private key authenticates a client to a server or Git host. Keep it on the protected client, register only the public key, verify host or key fingerprints before trusting a remote identity, and use separate keys for separate accounts or environments when practical.

TLS and HTTPS

A web server holds a private key and presents a certificate containing its public key and identity claims. A certificate authority signs the certificate to bind the public key to a hostname or identity. Restrict the key to the service account, or keep key operations inside an HSM or KMS. After compromise, replace the key and certificate and revoke the old certificate when applicable.

Software, documents, and email

A private signing key signs a release, document, or message; users verify it with the public key. Signing keys need stronger controls than ordinary build files because compromise can make malicious artifacts appear authentic. Prefer controlled release systems, hardware-backed keys, approval workflows, and audit logs.

Cloud services

A KMS or HSM can generate and use keys without giving applications raw exportable private-key files. Configure narrowly scoped permissions, separate administrative and use roles, monitor operations, and understand backup, deletion, export, and regional behavior.

Cryptocurrency wallets

The private key or recovery seed represents control over signing transactions. Disclosure can enable irreversible transfers, while loss can make funds permanently inaccessible. Use the wallet's approved backup model, protect recovery material offline, and never enter it into an untrusted website or application.

Safe Operational Practices

• Use a unique key for each purpose, system, or security boundary where feasible.
• Use strong, unique passphrases and hardware-backed or multi-factor controls when supported.
• Verify public-key fingerprints before trusting a remote identity.
• Never share a private key among people, applications, hosts, or environments unnecessarily.
• Use an SSH agent, HSM, KMS, or managed signing mechanism to reduce repeated key-file exposure.
• Keep cryptographic tooling, operating systems, libraries, and services updated.
• Follow organizational key-management, retention, rotation, and incident-response policies.
• Practice backup and recovery before a real failure.

Troubleshooting

SSH says private-key permissions are too open

The file may be readable by a group or other users, or its directory may be unsafe. Restrict the file to its owner, verify ownership, and inspect parent-directory permissions. On a POSIX system, chmod 600 ~/.ssh/id_ed25519_example is a common starting point.

A service cannot read its private key

Check the service identity, configured path, file owner, mode, and parent directories. Also check service sandboxing, SELinux, AppArmor, container mounts, and secret-store access policies. Grant only the minimum required access and review logs without printing key material.

The passphrase is forgotten

Restore a permitted encrypted backup or use an approved recovery mechanism. If recovery is impossible, generate a new pair and replace or revoke the old trust relationship.

The format is wrong

Identify the required algorithm, encoding, and container. The application may expect PKCS#8, OpenSSH, PEM, DER, or PKCS#12. Convert only in a secure environment, preserve restrictive permissions, and validate that the resulting public key matches the intended certificate or registration.

A key was committed or sent accidentally

Assume compromise immediately, even if the repository becomes private or the file is deleted. Generate and deploy a replacement, revoke or remove the old credential, investigate access, and remove exposed copies where possible. Deletion alone does not undo copying or cached history.

The certificate does not match the private key

The wrong pair may have been deployed, or rotation may have updated only one component. Use approved tooling to compare the public-key identity derived from the private key with the certificate's public key, then deploy the matching pair and reload the service safely.

Exam- and Interview-Relevant Notes

• The private key signs; the corresponding public key verifies.
• Data encrypted to a recipient's public key is decrypted with that recipient's private key.
• Public-key cryptography commonly establishes or protects a symmetric session key for bulk data.
• A public key cannot be used to reconstruct a secure private key.
• A passphrase protects a stored key file; it is not the private key itself.
• Changing a passphrase does not replace a compromised key.
• PEM is commonly text encoding; DER is binary encoding. PKCS#8, OpenSSH, and PKCS#12 describe containers or formats.
• After exposure, replace the key and revoke or remove the old trust relationship.

See also Private Key for this lesson's key-management reference.