Cryptography

Cybersecurity / 24 Sep 2026 / 5 min read

HTTP Message Signatures Bind Selected HTTP Components

TLS protects an HTTP exchange while traffic moves across a TLS connection, but some application designs need a cryptographic assertion attached to the HTTP message itself. A gateway may terminate TLS before forwarding a request, a service may need to authenticate selected request metadata, or a message may cross several HTTP hops where transport protection and application trust are separate concerns. HTTP Message Signatures, specified in RFC 9421, address that boundary. A signer chooses HTTP message components, constructs a defined signature base, signs it, and sends metadata that tells a verifier which components and parameters were covered. The mechanism is selective by design: a signature does not automatically cover every field or every property of the message.

Cybersecurity HTTP

Cybersecurity / 24 Sep 2026 / 5 min read

Certificate Transparency Separates Log Promises from Inclusion Proofs

A TLS certificate can be valid under normal chain validation and still deserve public scrutiny. Certificate Transparency (CT) adds that visibility by placing certificates or precertificates in public logs designed for auditing. The security model is more precise than a simple claim that a certificate has been logged: CT separates a log’s signed promise from later evidence that the promised entry actually reached the log’s Merkle tree. RFC 9162 describes CT version 2.0. A conforming log is an append-only Merkle tree. When it accepts a certificate or precertificate submission, it returns a Signed Certificate Timestamp (SCT). That SCT is a signed commitment associated with the accepted submission and a timestamp. It is not, by itself, a Merkle inclusion proof.

Cybersecurity TLS

Cybersecurity / 22 Sep 2026 / 6 min read

DNSSEC Authenticates DNS Data with a Signed Chain

DNSSEC Authenticates DNS Data with a Signed Chain DNS normally answers a naming question: which records are associated with a domain name? The protocol’s basic response path does not, by itself, give a validating resolver cryptographic evidence that the returned record set is the data authorized by the zone owner. DNS Security Extensions, or DNSSEC, add that evidence. A signed zone publishes public keys and signatures that allow a validating resolver to authenticate DNS data through a chain rooted in a configured trust anchor. DNSSEC protects authenticity and integrity of DNS data. It does not encrypt queries or responses, and it does not conceal the names being requested.

Cybersecurity DNS

Cybersecurity / 20 Sep 2026 / 7 min read

TLS 1.3 Session Tickets Carry Resumption State Across Connections

TLS 1.3 Session Tickets Carry Resumption State Across Connections A completed TLS 1.3 handshake can establish more than traffic keys for the connection that is already open. After the handshake, a server can issue a NewSessionTicket that gives the client material for a later resumption attempt. The later connection can then authenticate continuity with the earlier TLS session without repeating the same certificate-based handshake path. That optimization changes where security state lives. A deployment that enables resumption is no longer concerned only with the server certificate and the keys of the current connection. Ticket lifetime, resumption secrets, cached authentication attributes, ticket protection keys, and the rules used when accepting a resumed connection become part of the boundary.

Cybersecurity TLS 1.3

Cybersecurity / 19 Sep 2026 / 9 min read

Signal Protocol Is a Cryptographic Layer, Not a Transport Protocol

Signal Protocol Is a Cryptographic Layer, Not a Transport Protocol A Go service can deliver messages over WebSocket, HTTP, WebRTC, MQTT, or a store-and-forward queue without any of those transports providing end-to-end encryption. Transport encryption such as TLS protects a connection between network peers. Signal Protocol addresses a different boundary: message content is encrypted at one endpoint and remains ciphertext until the receiving endpoint processes the corresponding cryptographic session. That distinction determines where Signal Protocol belongs in an application. The relay can authenticate accounts, route envelopes, retain undelivered ciphertext, and enforce quotas, but it should not need the conversation keys required to recover message plaintext.

Cybersecurity Signal Protocol

Linux / 19 Sep 2026 / 4 min read

Random Hex Is Not a Hash: Generating Cryptographic Random Values on Linux

A command such as openssl rand -hex 32 is often described as generating a “random hash.” The output certainly looks like a SHA-256 digest: 64 hexadecimal characters. But no hash operation has happened. OpenSSL generated 32 random bytes and encoded them as hexadecimal. That distinction matters. A hash function transforms input into a fixed-size digest. A cryptographically secure random number generator produces unpredictable bytes. If the requirement is a token, session secret, API credential, nonce, or other fresh random value, the random bytes are the important part. Hashing them afterward usually adds no useful unpredictability.

Linux Randomness

Cybersecurity / 19 Sep 2026 / 7 min read

JWS Key Selection Is a Trust Decision, Not a Header Instruction

JWS Key Selection Is a Trust Decision, Not a Header Instruction A signed token can carry enough metadata to point a verifier toward a key. A JWS protected header can name an algorithm with alg, identify a key with kid, or, in profiles that permit them, carry or reference key material through parameters such as jwk, jku, x5c, or x5u. Those fields are useful for routing verification work, especially during key rotation.

Cybersecurity JWS

Cybersecurity / 19 Sep 2026 / 7 min read

fs-verity Binds Read-Only File Reads to a Merkle-Tree Digest

A file can be stored on media that is less trusted than the process consuming it. Making that file read-only through ordinary permission bits does not prove that the bytes later returned from storage are the bytes that were approved earlier. Linux fs-verity addresses that narrower integrity boundary for supported filesystems by binding reads from an enabled file to a Merkle tree and a stable file digest. The mechanism has two distinct security roles. The kernel verifies file data against the Merkle tree during reads. A separate policy must establish that the resulting fs-verity digest is the digest that the system intended to trust. Treating those roles as one guarantee overstates what the filesystem feature provides.

Cybersecurity Linux

Cybersecurity / 18 Sep 2026 / 7 min read

fs-verity Binds File Reads to a Merkle Tree Digest

A package manager can place an executable on a writable filesystem, close it, and later expect every byte returned from that file to match a previously approved object. Ordinary permissions can stop cooperative writers, but they do not turn file contents into a cryptographically identified object. Linux fs-verity supplies that narrower property for individual files: after verity is enabled, file data becomes read-only and reads are checked against a Merkle tree rooted in a stable file digest.

Cybersecurity Linux

Cybersecurity / 15 Sep 2026 / 7 min read

SSH Host Key Pinning Turns First Contact Into a Persistent Trust Decision

SSH Host Key Pinning Turns First Contact Into a Persistent Trust Decision An SSH client can negotiate strong encryption with the wrong server. The cryptographic channel may be intact while an active intermediary terminates one SSH connection and creates another, unless the client has a reliable basis for authenticating the server’s host key. OpenSSH addresses that boundary with host key verification. A client records or otherwise obtains trusted host key material and checks the key presented during later connections. This converts server identity from a property inferred from network routing into a cryptographic comparison anchored in local or externally authenticated state.

Cybersecurity SSH

Cybersecurity / 15 Sep 2026 / 8 min read

JWKS Rotation Makes Cache Lifetime Part of Token Verification

A service receives a valid JWT seconds after its issuer rotates signing keys. The token carries a new kid, but the verifier still has the previous JWK Set in cache. Signature verification cannot even begin with the correct public key until the verifier obtains a set containing that identifier. This is a routine rollover condition, not a cryptographic break. Yet it exposes an important boundary in distributed token validation: a verifier that obtains public keys remotely depends on cache behavior and key publication timing alongside the signature algorithm itself.

Cybersecurity JWT

Cybersecurity / 15 Sep 2026 / 8 min read

DNSSEC Validation Makes DNS Tampering Detectable at the Resolver

DNSSEC Validation Makes DNS Tampering Detectable at the Resolver A recursive resolver can receive a syntactically valid DNS answer from the network and still have no cryptographic evidence that the answer came from the zone responsible for the name. Transaction identifiers, source-port randomization, and transport controls make blind forgery harder, but they do not turn ordinary DNS records into authenticated data. DNS Security Extensions add that missing property for signed portions of the namespace. Resource-record sets carry signatures, zones publish signing keys, and parent zones can bind child keys into a chain rooted in a configured trust anchor. A validating resolver can then classify data according to cryptographic evidence instead of accepting an answer solely because it arrived through the expected DNS exchange.

Cybersecurity DNS

Cybersecurity / 15 Sep 2026 / 7 min read

DNSSEC Makes DNS Data Verifiable Across Resolver Boundaries

DNSSEC Makes DNS Data Verifiable Across Resolver Boundaries A recursive resolver can receive a DNS response from the expected network address and still lack cryptographic proof that the record came from the zone owner. Traditional DNS uses transaction matching, delegation structure, and transport behavior to associate replies with queries. Those controls can reject many stray packets, but they do not make returned resource-record data cryptographically verifiable. DNS Security Extensions, commonly called DNSSEC, add signatures and a chain of authenticated delegation to that model. A validating resolver can test whether signed data corresponds to a key authorized through the DNS hierarchy. The result is narrower than encrypted DNS: DNSSEC authenticates DNS data, not the confidentiality of the query path.

Cybersecurity DNS

Cybersecurity / 11 Sep 2026 / 7 min read

Compare Secret Values in Constant Time

A server often needs to decide whether an untrusted value matches a secret value it already knows. Examples include verifying a message authentication code (MAC), checking a high-entropy API token, or validating a signed-request tag. A normal equality operation may stop as soon as it finds a different byte. That behavior is efficient, but the amount of work can then depend on where the first difference appears. Under suitable conditions, repeated timing observations can expose information about the secret comparison.

Cybersecurity Secure Coding

Cybersecurity / 08 Sep 2026 / 10 min read

Use Authenticated Encryption for Data You Must Trust

Encrypting sensitive data can hide its contents while still leaving an important question unanswered: has the encrypted data been changed? If an application decrypts modified ciphertext without a reliable integrity check, it may consume attacker-influenced plaintext even though the attacker never learned the encryption key. That distinction matters anywhere decrypted data affects a security decision, a payment amount, a permission, a destination, or another meaningful application state. Confidentiality answers who can read the data. Integrity answers whether the protected data is the same data that an authorized key holder produced.

Cybersecurity Encryption

Cybersecurity / 07 Sep 2026 / 9 min read

Compare Secret Values Without Timing Leaks

Applications compare security-sensitive values constantly: message authentication codes, webhook signatures, API tokens, recovery codes, and other secret authenticators. A normal string or byte comparison may stop as soon as it finds a mismatch. That is efficient, but when the compared value is secret, the amount of work can depend on how much of the candidate matched. If an attacker can obtain useful timing measurements over many attempts, data-dependent comparison time can become an information leak. The practical defense is not to write a clever comparison loop. Use a well-reviewed constant-time comparison primitive provided by the language, cryptographic library, or platform for secret values of the expected form.

Cybersecurity Secure Coding

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 / 06 Sep 2026 / 9 min read

Compare Secret Values with Constant-Time Functions

A verifier often ends with a simple question: does a value derived from this request match the value the system expects? That question appears when checking message authentication codes, signed-request authenticators, reset-token digests, and other security-sensitive values. Using an ordinary string or byte comparison can introduce a subtle problem. Some comparison routines stop as soon as they find the first difference. Their work can therefore depend on how much of the input matches. If an attacker can make many measurements under sufficiently stable conditions, that timing difference may reveal information about a secret-dependent value.

Cybersecurity Secure Coding

Cybersecurity / 05 Sep 2026 / 9 min read

Store Passwords for Offline Attack Resistance

A login system needs to recognize a password later, but it does not need to recover the original password. That distinction should shape how passwords are stored. If an application stores plaintext passwords, reversible encrypted passwords, or fast general-purpose hashes, a database disclosure can turn into a much larger authentication problem. An attacker who obtains password verifiers can make guesses on their own hardware, without sending each attempt through the application’s login endpoint. Online rate limits no longer control that work.

Cybersecurity Authentication

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 / 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 / 11 min read

Keep Encryption Nonces Unique

Modern authenticated encryption can protect both the confidentiality and integrity of data, but some algorithms depend on a small operational rule that is easy to overlook: do not reuse a nonce with the same key. A nonce is a value supplied to a cryptographic operation for a particular invocation. The word comes from “number used once,” but a nonce is not necessarily secret and is not necessarily a simple counter. What matters is the requirement of the algorithm using it. For widely used authenticated-encryption schemes such as AES-GCM and ChaCha20-Poly1305, nonce reuse under the same key can invalidate important security guarantees.

Cybersecurity Encryption

Cybersecurity / 02 Sep 2026 / 7 min read

Constant-Time Comparison for Authentication Tags and Secret Values

Security-sensitive verification often ends with a simple question: does an untrusted value equal the value the server expected? For ordinary application data, a normal equality operator is appropriate. For authentication tags and some secret values, however, an equality operation that stops at the first mismatch can expose information through execution time. Timing-safe comparison APIs reduce that risk by avoiding content-dependent short-circuit behavior. They are small tools, but using them correctly requires more than replacing one equality operator.

Cybersecurity Cryptography