Key Moments

The Private Key Mistake! (TLS Key set to "4") - Computerphile

ComputerphileComputerphile
Education5 min read25 min video
Oct 30, 2026|157,952 views|2,235|345
Save to Pod
TL;DR

A certificate authority used '4' as a private key, a number so small it was brute-forced in seconds, undermining the entire public key infrastructure.

Key Insights

1

A private key for TLS connections is typically around 384 bits, equating to roughly 120 digits, making '4' an astronomically small and insecure choice.

2

The compromised certificate authority, Emraudra, used private keys with values '4', '56', '151', '66', '155', '156', '230', and '237', none of which are cryptographically sound.

3

Standard cryptography tools like OpenSSL are designed to randomly generate private keys and do not offer a direct option to input a specific, small private key, highlighting the unusual nature of the error.

4

The process of generating a public key uniquely from a private key, a core principle of elliptic curve cryptography, allows for the verification of a found private key by checking its corresponding public key.

5

A brute-force script, even a slow one taking one second per operation, could find a private key like '115' relatively quickly, demonstrating the severe vulnerability introduced by such a small number.

6

While modern systems would likely reject certificates signed with these weak keys due to updates, older or offline systems might still be vulnerable if they haven't received security patches.

The shocking discovery of a private key set to the number '4'

The security world was rocked when it was revealed that a certificate authority, Emraudra, had used the private key '4' for its operations. This is an almost incomprehensibly small value when compared to the typical size of private keys used in TLS (Transport Layer Security) connections. A standard private key is usually around 384 bits, which translates to approximately 120 decimal digits. The number '4' is so minuscule in this context that it would take mere seconds to brute-force, rendering any security provided by that key utterly useless. This mistake fundamentally undermines the trust placed in the public key infrastructure that secures online communications.

Understanding the public key infrastructure and TLS connections

To establish a secure connection, like visiting your bank's website or even a seemingly less sensitive site like the BBC, your browser initiates a TLS connection. This process relies on public key cryptography. When you connect to a website, it presents its public key, typically embedded in a digital certificate. The crucial question is how your browser can be sure that this public key genuinely belongs to the BBC and not to a malicious actor impersonating the BBC. This is where certificate authorities (CAs) come in. They act as trusted intermediaries, vouching for the authenticity of public keys by signing certificates. This chain of trust extends from the website's certificate, signed by an intermediate CA, which is in turn signed by a root CA. Your browser has a pre-installed list of trusted root CA public keys, allowing it to verify the entire chain back to a known, trusted source. The private key is intrinsically linked to the public key; the private key is used to create a signature, which can then be verified by anyone using the corresponding public key. If an attacker obtains the private key, they can effectively impersonate the legitimate owner and sign fraudulent certificates.

The vulnerability of weak private keys

The core issue with Emraudra's mistake is that a private key's strength relies on its size and randomness. A private key should be a very large, unpredictable number, making it computationally infeasible to guess or derive. When a private key is as small as '4', or other reported weak values like '56', '151', '66', '155', '156', '230', and '237', it becomes trivial to find. This is because the underlying mathematical problems used in cryptography are designed to be difficult only when the numbers involved are large. An attacker doesn't need sophisticated hacking tools; they simply need to try a limited, predictable set of numbers. In this case, '4' could be guessed almost immediately, allowing an attacker to generate a valid signature for a fake certificate, effectively compromising any connection that relied on Emraudra's compromised certificates.

The challenge of deliberately setting a weak private key

The process of generating cryptographic keys is designed to ensure randomness and security. Tools like OpenSSL, when used for key generation, are built to create random private keys. They typically do not offer a direct function to specify a particular private key value, such as '4'. This makes the mistake by Emraudra even more perplexing. The video explores how one might attempt to manually construct a key pair with a specific private key, encountering difficulties with standard tools. This suggests that Emraudra might have used custom, non-standard, or deeply flawed methods to generate their keys, perhaps even using specialist hardware in a way that allowed for predetermined values. The usual method involves a one-to-one mapping between a private key and its corresponding public key.

Demonstrating the brute-force attack

To illustrate the ease of exploitation, the video demonstrates a script that attempts to find a private key by iterating through numbers and generating corresponding public keys. The principle is that if the generated public key matches the public key extracted from a compromised certificate, then the iterated private key is the correct one. The presenter shows how to extract the public key from a certificate and then uses a Python script to loop through potential private keys. This script generates a private key, derives its public key using OpenSSL, saves it, and compares it to the known public key from the certificate. Even with a relatively slow script, the process of finding a key like '115' (one of the reported weak keys) is shown to be quick, highlighting the severity of the vulnerability. The comparison is done by comparing the extracted public key files, a reliable proxy for comparing the public keys themselves.

The implications for trust and security

The consequence of this type of breach is that any website or service that used a certificate signed by Emraudra with a compromised private key is effectively untrustworthy. An attacker could have created fake certificates for legitimate websites, intercepting user traffic and potentially stealing sensitive information. While modern systems are likely updated to reject these fraudulent certificates, the incident serves as a stark reminder of how a single, seemingly simple mistake in key management can have catastrophic security implications. It underscores the importance of rigorous key generation practices, regular security audits, and prompt patching of systems to prevent such vulnerabilities from being exploited.

Secure Key Practices: Do's and Don'ts

Practical takeaways from this episode

Do This

Use cryptographically secure, randomly generated private keys of sufficient length (e.g., 384 bits).
Understand the process of public key infrastructure (PKI) and certificate chains.
Employ specialist hardware for creating private and public key pairs when possible.
Regularly update systems and software to ensure they recognize revoked or compromised certificates.
Verify that your tools allow for the secure generation and management of private keys.

Avoid This

Never use small, predictable numbers (like '4', '56', '151') as private keys.
Do not assume a certificate is valid without verifying its signature and chain of trust.
Avoid using default or easily guessable private keys.
Do not rely on manual modification of keys or certificates for security.
Do not use outdated systems that may not recognize security patches or revoked certificates.

Common Questions

A private key is a secret cryptographic code that, when paired with a public key, allows for secure digital communication. It's used to create digital signatures, proving your identity and ensuring the integrity of data. If compromised, an attacker can impersonate you.

Topics

Mentioned in this video

More from Computerphile

View all 94 summaries

Ask anything from this episode.

Save it, chat with it, and connect it to Claude or ChatGPT. Get cited answers from the actual content — and build your own knowledge base of every podcast and video you care about.

Get Started Free