Understanding cryptographic algorithms in Venafi Trust Protection Platform

Introduction to machine identity security

In modern enterprise environments, machines—including servers, containers, applications, and cloud workloads—interact far more frequently than users do. These machines require unique identities to authenticate securely, establish trust, and protect data. Machine identity security refers to the systems and practices used to manage and protect the digital credentials that enable this trust.

Without effective machine identity security, organizations face serious risks:

• Outages due to expired certificates

• Unauthorized access from orphaned or improperly managed SSH keys

• Compromise of software integrity through misuse of code signing credentials

• Compliance violations due to weak or outdated cryptography

Machine identities are foundational to securing both internal systems and external-facing services. If you are new to this topic, here are some key concepts that will help you understand how Trust Protection Platform helps protect your network.

• Machine identities use cryptographic keys and certificates. Jump to section

• TLS certificates identify trusted machines through trusted relationships. Jump to section

• SSH keys and certificates also identify trusted machines. Jump to section

• Code signing allows you to trust that code hasn't been changed since it was packaged. Jump to section

• Cryptographic algorithms serve different purposes. Jump to section

• Algorithm choice impacts machine identity security. Jump to section

• Central management of machine identities protects your network and ensures trusted communication. Jump to section

Each of these key concepts is described in more detail in the sections that follow.

Machine identities use cryptographic keys and certificates

Machine identities establish trust between systems. The most common machine identity types include:

• TLS certificates: Used to authenticate web servers, APIs, containers, and other systems to clients or other machines. TLS certificates are used to establish trust for the TLS handshake.

• Code signing certificates: Used to prove that a document, application, or other digital data originated from a trusted source and has not been modified.

• SSH keys and certificates: Used for remote access and automation, often between development tools and systems, or between machines.

Each of these cryptographic assets uses asymmetric cryptography. A private key must remain secure and should never leave the system that owns it. A certificate (or public key, if no certificate is involved) is intended to be distributed and used by others to authenticate the holder of the private key.

To ensure trust is never broken, machine identities have a lifecycle. A key must not be used for longer than a specified validity period to protect against brute-force (and other) attacks. Keys need to be tracked to determine when they need to be rotated and when certificates expire. A certificate must be revoked in case of key compromise (trust is broken on purpose).

Without a system to manage these assets, organizations risk outages, vulnerabilities, and unauthorized access.

TLS certificates identify trusted machines through trusted relationships

A TLS certificate proves to a client that a machine—usually a server or service endpoint—is the correct entity. A Certificate Authority (CA) is used to validate an entity and to issue a certificate. A client that trusts the CA will therefore trust a certificate issued by the CA.

A certificate can contain information about the server or service endpoint, including at least a validity period, information about the entity like its locality and name, the service or server name, and the public key.

When a client connects to a server over HTTPS (or any other TLS-enabled protocol), it checks to see if the certificate:

• Was issued by a trusted certificate authority (CA)

• Is currently valid (not expired or revoked)

• Matches the domain of the server or service

• Uses cryptography that meets with current security standards

If these checks fail, the client refuses to trust the server.

Because TLS certificates are often deployed across many systems and environments, managing them at scale introduces additional complexity. Expired certificates can cause outages. Certificates using deprecated algorithms (like SHA-1) can introduce vulnerabilities. Venafi TLS Protect helps organizations discover, manage, and renew these certificates securely and automatically.

SSH keys and certificates also identify trusted machines

SSH (Secure Shell) is commonly used for remote administration and automation between systems. Unlike TLS certificates, SSH does not rely on a certificate authority. Instead, mutual trust is established by first exchanging public keys.

Each SSH key pair consists of:

• A public key, which is copied to machines where holders of the private key should be permitted access.

• A private key, which must be kept secure by the user or system initiating the connection.

When a system initiates an SSH connection to another system, it acts as the SSH client, and the target system acts as the SSH server. The client verifies the server’s identity by checking the server’s public key against entries in the client’s known_hosts file. If the key matches, the server checks whether the client’s public key is listed in the server’s authorized_keys file. If the client proves ownership of the corresponding private key, access is granted without requiring a password.

SSH keys are powerful, but unmanaged key sprawl is a major security risk. Keys can be duplicated, reused, or left behind when employees change roles or leave the company. Without visibility or policy enforcement, it's difficult to know which keys are valid or necessary.

Venafi SSH Protect helps discover and analyze trusted keys across systems. It enables organizations to audit access, remove unused or unauthorized keys, and ensure that only approved cryptographic algorithms and key sizes are used. Like with TLS certificates, organizations can rotate keys as needed to protect against brute force attacks or compromised keys.

Code signing enables you to trust that digital assets have not been changed

Code signing validates that a document, application, or other digital data originated from a trusted source and has not been modified. When an asset is signed, a digital signature is applied using a private key. Recipients can use the corresponding public key to verify:

• The asset came from a known, trusted publisher.

• The asset has not been modified since it was signed.

Signed assets include applications, documents, scripts, drivers, container images, and more. Most modern operating systems and platforms display warnings or block an asset that is unsigned, signed but altered, or signed by an untrusted party.

If a code signing private key is misused or stolen, attackers can distribute malicious assets that appear legitimate. This risk is amplified in supply chain attacks where compromised software affects downstream users.

Venafi CodeSign Protect secures and governs code signing keys (whether secured by CodeSign Protect or a supported HSM), enabling you to implement approval workflows, and audit all signing activity. These capabilities help prevent misuse and enforce compliance. Like with TLS certificates and SSH keys, organizations can rotate code signing keys as needed to protect against brute force attacks or compromised keys.

Cryptographic algorithms serve different purposes

Machine identities use a variety of cryptographic algorithms, each used for a specific function. The following types of cryptographic algorithms are commonly used in machine identity systems:

• Asymmetric algorithms support identity verification and digital signatures. These algorithms are most commonly used for certificate issuance and code signing applications. Common algorithms include RSA, Elliptic Curve, and ED25519, among many others.

  Asymmetric encryption uses a pair of keys, a private key to sign data, and a public key to verify a signature. In the case of SSH, the public key is immediately available. In the case of TLS, the public key comes from a certificate.

• Symmetric encryption algorithms are used for encrypting data in transit or at rest. Common algorithms include AES, among many others.

  Symmetric encryption uses the same key for both encryption and decryption, which is why in the case of data in transit, after establishing trust via asymmetric encryption, messages between machines use symmetric encryption.

• Hash functions, such as SHA-256, generate fixed-length digests used in signatures and integrity checks.

  Hashing is a widely-used method for verifying data integrity. A hash function converts arbitrary data into a fixed-length string (a hash) that is unique to the original data. Hashing algorithms include SHA2 and SHA3.

  Hashing algorithms are used to reduce the amount of data to be signed. Instead of signing the actual digital asset, they creating a hash of the asset and then sign the hash.

  Hashing is irreversible—you cannot obtain the source data from a hash. A hash (sometimes also called a digest) is like a unique digital fingerprint for any piece of data.

• Quantum-safe algorithms (also known as Post-Quantum Cryptography or PQC) are designed to resist attacks that would only be possible on a quantum computer. Quantum computers are expected to eventually break traditional public-key systems like RSA and elliptic curve (EC) cryptography using Shor’s algorithm. In contrast, quantum-safe algorithms are based on complex mathematical problems—such as lattice-based or multivariate polynomial equations—that are believed to be resistant to quantum attacks.

  While quantum computing poses future challenges to public-key cryptography, symmetric encryption and hash functions remain secure due to the longer key and hash lengths in use today.

  Research on quantum-safe algorithms is ongoing, and standards in this area are still evolving. Venafi already supports—and will continue to develop support for—quantum-safe cryptography to help customers prepare for the quantum future.

  One of the most urgent concerns in post-quantum cryptography is the risk of "harvest now, decrypt later" attacks, in which encrypted data is collected today and stored for future decryption using quantum computers. Organizations can mitigate this risk by adopting quantum-safe algorithms proactively.

  One approach to ensuring compatibility and security during the transition to post-quantum cryptography is to use composite digital signatures, which combine a classical cryptographic algorithm with a post-quantum algorithm in a single signature structure. This method is described in the Internet Engineering Task Force (IETF) draft specification Post-Quantum Composite Signatures, published by the LAMPS working group. The draft outlines how to create and validate digital signatures that incorporate both legacy and quantum-resistant algorithms, providing cryptographic agility and helping organizations maintain long-term data security.

  Composite algorithm standards are actively under development. The ISO/IEC 14888-4 specification defines how to generate and validate digital signatures that incorporate multiple algorithms. Although this specification has not yet been finalized, it represents a key step in global standardization efforts.

  Beginning with version 25.1, Trust Protection Platform includes support for several composite algorithms. Because standards are still evolving, some algorithms supported today may be deprecated in the future if they are not included in the final standards.

Each algorithm offers different performance and security trade-offs.

Algorithm choice impacts machine identity security

Using outdated or weak algorithms can undermine the security of a machine identity. Common risks include:

• Deprecated algorithms, such as SHA-1 or MD5, are vulnerable to collision or forgery attacks.

• Short key lengths, such as 1024-bit RSA, are no longer considered secure and can be brute-forced with modern computing power.

Organizations should adopt and enforce algorithm standards, such as:

• RSA keys with a minimum length of 2048 bits
• EC keys with a minimum length of 256 bits
• SHA2 (SHA-256 or stronger) for all digital signatures

Trust Protection Platform allows you to define cryptographic policy, discover non-compliant certificates or keys, and remediate them through automated replacement.

Central machine identity management protects your network and ensures trusted communication

As environments grow more complex, manual certificate and key management becomes unsustainable. Without centralized control, machine identities may:

• Expire unexpectedly, causing outages.

• Use non-compliant or outdated algorithms or key sizes.

• Persist after they are no longer needed, increasing attack surface.

Centralized machine identity security provides:

• Visibility into where keys and certificates are deployed and how they are used.

• Automation to handle rotation, renewal, replacement, and revocation at scale.

• Policy enforcement to ensure all identities meet organizational and regulatory standards.

• Auditing and reporting to support compliance and incident response.

Venafi Trust Protection Platform delivers centralized lifecycle management across TLS certificates, SSH keys and certificates, and code signing keys and certificates. It enables organizations to operate securely, meet regulatory requirements, and maintain trust across machine-to-machine communication.