Key Management

Cybersecurity / 24 Sep 2026 / 6 min read

TLS Delegated Credentials Limit Certificate Key Exposure

Large TLS deployments often need signing capability on many serving machines. Copying the certificate private key to every endpoint expands the set of systems whose compromise can expose a long-lived credential. Keeping that key in one tightly controlled location reduces exposure, but remote signing for every handshake can add an operational dependency to the serving path. Delegated Credentials for TLS, standardized in RFC 9345, provide a narrower option for TLS 1.3. A certificate holder can use its certificate private key to authorize another public key for a limited period. The endpoint receives the corresponding delegated private key and can authenticate TLS handshakes without holding the certificate private key itself.

Cybersecurity TLS

Cybersecurity / 21 Sep 2026 / 5 min read

TLS Delegated Credentials Limit Front-End Key Exposure

TLS Delegated Credentials Limit Front-End Key Exposure A large TLS deployment often terminates connections on machines far from the system that manages its certificate private key. Copying that long-lived key to every front end simplifies handshakes, but it also enlarges the set of systems whose compromise can expose the certificate key. RFC 9345 defines delegated credentials for TLS and DTLS 1.3. A certificate holder can sign a separate, short-lived credential containing another public key. A compatible endpoint then uses the delegated credential and its private key for handshake authentication while the certificate private key can remain in a more restricted environment.

Cybersecurity TLS 1.3

Cybersecurity / 21 Sep 2026 / 6 min read

SSH Host Key Verification Binds Connections to Server Identity

SSH Host Key Verification Binds Connections to Server Identity SSH encrypts a connection, but encryption alone does not establish that the endpoint is the intended server. During key exchange, the server proves possession of a host private key. The client then has to decide whether the corresponding public identity is trusted for that host. That decision is the host-authentication boundary. If a client accepts an attacker’s host key without a valid trust basis, the resulting channel can still be encrypted while terminating at the wrong machine. Passwords, commands, forwarded agents, and session data can then cross a boundary the operator did not intend.

Cybersecurity SSH

Cybersecurity / 08 Sep 2026 / 11 min read

Use Envelope Encryption to Limit Key Exposure

Encrypting sensitive data is only part of the design problem. The application also needs access to the encryption key, and that key must be stored, rotated, authorized, backed up, and eventually retired. If one long-lived key directly encrypts every record, changing how that key is protected can become tightly coupled to re-encrypting all of the data. Envelope encryption separates those jobs. Data is encrypted with a data-encryption key, while that data key is itself protected by another key. This extra layer does not make encryption magically stronger. Its value is operational: it lets a system protect many data keys behind a smaller set of tightly controlled key-encryption keys and change the outer protection without necessarily rewriting the underlying data.

Cybersecurity Encryption

Cybersecurity / 06 Sep 2026 / 9 min read

Rotate Encryption Keys Without Losing Access to Data

Encrypting stored data creates a second problem that is easy to overlook: the application must keep the right decryption key available for as long as the protected data still needs to be read. If an application replaces an encryption key and immediately deletes the old one, existing ciphertext may become permanently unreadable. If it never replaces keys, one long-lived key can accumulate more data and more operational exposure than intended. A practical design needs to support both change and continuity.

Cybersecurity Cryptography

Cybersecurity / 06 Sep 2026 / 12 min read

Design Cryptography for Algorithm Change

Applications often keep encrypted records, signed objects, or authentication data for much longer than the code that first created them. During that lifetime, a cryptographic algorithm may be deprecated, a parameter may become too weak, a library may change, or an organization may need a different key-management design. The difficult part is usually not adding the new cryptographic operation. It is changing the system without making old data unreadable, silently accepting an unintended algorithm, or leaving legacy protection in place forever.

Cybersecurity Cryptography

Cybersecurity / 05 Sep 2026 / 9 min read

Rotate Encryption Keys Without Losing Access to Existing Data

Encrypting sensitive data creates a long-term dependency that is easy to overlook: the application must retain the right decryption capability for as long as the ciphertext remains useful. Replacing an encryption key without planning for that dependency can make old data unreadable. Keeping one key forever avoids that immediate problem but makes future key changes harder and can increase the amount of data tied to one key. The practical solution is key versioning. Each ciphertext records which key version protects it. New encryption uses the current key, while decryption can temporarily use older versions for data that has not yet been migrated.

Cybersecurity Cryptography

Cybersecurity / 05 Sep 2026 / 11 min read

Design Encryption for Cryptographic Erasure

Deleting a database row or object does not necessarily remove every physical copy of its bytes. Storage systems may keep replicas, snapshots, backups, or blocks that are no longer visible through the application. When sensitive data must become inaccessible, finding and overwriting every copy can therefore be difficult. Encryption can change this problem. If data is encrypted under a key that can be reliably destroyed, destroying that key can make the remaining ciphertext infeasible to decrypt. This technique is called cryptographic erasure.

Cybersecurity Encryption

Cybersecurity / 04 Sep 2026 / 9 min read

Separate Cryptographic Keys by Purpose

Applications often need cryptographic keys for several jobs: encrypting stored data, authenticating messages, signing tokens, or protecting backups. It can be tempting to create one strong secret key and reuse it everywhere. That reduces the number of secrets to manage, but it also connects security boundaries that should remain independent. If the shared key is exposed, every use of that key may be affected at once. Reuse can also make permissions, rotation, incident response, and cryptographic assumptions harder to reason about.

Cybersecurity Cryptography

Cybersecurity / 04 Sep 2026 / 8 min read

Rotate Encryption Keys Without Losing Data

Encryption keys are long-lived security dependencies. A key may need replacement because its access policy changed, an operator left, a cryptographic policy changed, or there is reason to suspect exposure. The difficult part is not generating a new key. It is changing keys without making existing ciphertext unreadable or quietly continuing to depend on the old key forever. This process is called key rotation: introducing a new key for a defined cryptographic role and moving the system away from the old one in a controlled way.

Cybersecurity Encryption

Cybersecurity / 03 Sep 2026 / 10 min read

Protect Encryption Keys with Envelope Encryption

Encrypting sensitive data is only useful if the keys are protected as carefully as the data itself. A common mistake is to focus on the encryption algorithm while treating key storage as a secondary detail. If an attacker can obtain both the ciphertext and the key that decrypts it, the encryption no longer provides the intended protection. Envelope encryption addresses this operational problem by using different keys for different jobs. A data encryption key encrypts the data, while a separate key-encryption key protects the data key. This separation makes it possible to encrypt many pieces of data without storing their plaintext data keys beside them.

Cybersecurity Encryption