Cryptography, PKI, and key management

Cryptography, PKI, and key management

A designer chooses a cryptographic tool only after defining the objective. Symmetric encryption uses the same secret for encryption and decryption. It efficiently protects large data volumes, but distributing that secret is difficult. Asymmetric cryptography uses a public and private key; a public key can protect small key material or verify a signature, but the operations are slower and normally do not encrypt an entire long session. TLS combines both approaches: certificates and asymmetric operations authenticate the server and help establish session secrets, while symmetric algorithms protect session traffic. Hashing is not encryption. It produces a fixed-length value used to detect change and is not intended to recover the original text. When a vendor publishes a SHA-256 value, the recipient can hash the downloaded file and compare values, but this alone does not prove vendor identity if an attacker replaced both the file and the published value. A signature made with a trusted private key adds origin evidence. Passwords should not be stored with a fast hash alone; a password-derivation function uses a unique salt and appropriate cost to make large-scale guessing more expensive. Algorithm choice also depends on key length, mode, random generation, and key handling. A strong algorithm with an exposed key provides no meaningful protection.

Public key infrastructure binds an identity to a public key through a certificate signed by a certification authority. During a server connection, checking that a certificate is merely within its date range is insufficient. The client checks hostname matching, the chain to a trusted root, validity dates, permitted key usage, and revocation status when available. A self-signed certificate can still encrypt traffic, but a new client has no independent reason to trust its identity unless the certificate fingerprint or root was delivered through a trusted channel. A certificate signing request contains the public key and requested identity; the private key remains with its owner. If the private key leaves the system during request creation, another party may impersonate the server even when issuance was correct. Sensitive keys are therefore generated in an HSM or suitable secret store, with permissions controlling use rather than only file reading. Revocation addresses compromise or invalid identity before normal expiration. Routine renewal limits exposure but does not replace revocation planning. Expiration also needs monitoring: an outage caused by an expired certificate is an availability failure caused by operations, not a mathematical weakness in the cryptographic algorithm.

Worked case: a payment API needs transport confidentiality, request integrity, and server authentication. The team installs a CA-issued TLS certificate matching the hostname and disables obsolete protocol versions and cipher choices after documenting client compatibility. The private key remains in a non-exportable key store, and only the server process can invoke it. After deployment, an independent client verifies the chain, name, dates, and negotiated algorithm, submits a test request, and confirms that packet capture does not reveal its contents and that the response remains intact. For settlement-file integrity, the system hashes the file and signs the hash with a separate signing key. The recipient verifies the signature and certificate before accepting the file. The TLS key is not reused for every purpose: separation limits compromise impact and permits revoking one use without disabling another. The key record names the owner, location, creation and rotation dates, permitted uses, approved backup if any, and revocation and recovery procedures. Recovery is tested with encrypted sample material rather than inferred from the existence of a backup job. If an encryption key is lost without an authorized recovery copy, the data may be permanently unrecoverable; that security property must be part of the design decision before production.

A key lifecycle covers generation from suitable randomness, storage, distribution, use, rotation, revocation, and destruction. Each stage has a different threat. Emailing a symmetric key defeats secure distribution, copying a private key to many hosts expands theft exposure, and deleting an expired certificate without records can hinder verification of old signatures. Encryption and signing keys are separated, and services receive permission to use a key inside an HSM rather than export it. Rotation testing creates a new key, publishes its identifier, retains the old key for bounded decryption, then re-encrypts or securely destroys material. A compromise plan defines revocation, certificate replacement, and a search for misuse. A hash or certificate alone is not “proof of security”; evidence is successful verification within appropriate trust, key protection, algorithm, and usage policy.

During signing-key rotation, today's signatures use the new key, while validation of old documents may need the old public certificate and historical revocation information. Do not retain old private signing authority solely for verification. Separate public verification records from permission to create new signatures. In a controlled exercise, sign one sample before rotation and another afterward. Verify both through their appropriate certificates, then attempt a new signature with the retired key and expect denial. The test proves that historic verification remains possible without granting continuing signing authority to a key the organization intended to retire.