Public-Key Cryptography

Public-key cryptography, also called asymmetric cryptography, uses a pair of mathematically related keys. Disclosing the public key should not make deriving the private key computationally feasible when appropriate algorithms and key sizes are used. Depending on the algorithm, the pair supports encryption, digital signatures, or key agreement. These operations are distinct: RSA can support encryption and signatures through different schemes, while Ed25519 is a signature algorithm, not an encryption algorithm.

For confidentiality, an appropriate encryption scheme allows someone to encrypt data with the recipient's public key so that only the corresponding private key can decrypt it. For signatures, the private key signs data and the public key verifies the signature. A signature provides integrity and evidence that the signer controls the private key; it does not hide the signed data. Describing signing as simply encrypting with a private key is misleading and does not accurately describe modern signature schemes.

Cloud connections typically combine asymmetric and symmetric cryptography. During a modern TLS handshake, certificates and signatures authenticate the server, while key agreement establishes shared secrets from which symmetric traffic keys are derived. Symmetric encryption then protects application traffic efficiently. Public-key cryptography is generally not used to encrypt large application payloads directly because it is more computationally expensive and, for encryption schemes such as RSA-OAEP, has strict message-size limits.

A certificate binds a public key to an identity through an issuer's signature. An X.509 server certificate includes identity information, validity dates, and extensions such as subject alternative names. Clients must validate the certificate chain, validity period, intended usage, and requested hostname. Possessing a certificate alone does not prove ownership: the server must also demonstrate control of the corresponding private key. A certificate signing request contains the public key and requested identity information, not the private key.

For a local HTTPS development endpoint, OpenSSL can generate a private key and a self-signed certificate. For example, run openssl req -x509 -newkey rsa:3072 -sha256 -days 7 -keyout dev.key -out dev.crt -subj '/CN=localhost' -addext 'subjectAltName=DNS:localhost'. This command prompts for a passphrase to protect the private key. A self-signed certificate is not automatically trusted by browsers or other clients; explicitly configure trust in the development environment rather than disabling certificate validation. For teams, a dedicated development certificate authority can provide a more manageable trust model.

SSH uses public-key cryptography for authentication without requiring an X.509 certificate. Generate a development key pair with ssh-keygen -t ed25519 -f ~/.ssh/dev_ed25519 and choose a passphrase. Install only the .pub file's contents in the target user's authorized_keys file, and keep the private key on the client with restrictive permissions, such as chmod 600 ~/.ssh/dev_ed25519. SSH authentication proves possession through a signature; it does not send the private key to the server. Verify the server's host-key fingerprint separately to avoid connecting to an impostor.

In cloud environments, certificate managers automate certificate issuance and deployment, virtual machines accept SSH public keys, and managed key services protect asymmetric private keys for signing or decryption. Keep development and production keys separate, never commit private keys to source control, and plan certificate renewal and key replacement. A passphrase protects a stored private-key file but does not eliminate risk after the key is unlocked. Replacing a compromised SSH key also requires removing its old public key from every authorized location; issuing a new pair alone does not revoke access.