How ransomware is affecting the cyber insurance industry
Ransomware attacks have changed significantly in recent years, leaving every company vulnerable.
An almost unbelievable blunder by a global cybersecurity operator called eMudhra spawned a rash of dramatic media stories and social media memes, with lots of them repeating jokes along the lines of MY PRIVATE KEY IS 4!
But what does that really mean?
Why is a private key of 4 worse than any other? What trouble could this have caused? What cryptographic algorithm was being used, and how does it really work anyway?
Paul Ducklin digs under the news in this two-part explainer that anyone can understand, that everyone will enjoy, and that could help you avoid the same sort of mistakes yourself.
In October 2026, a curious cybersecurity crisis arose that posed a potentially huge risk to the global online community, due to a bizarre cryptographic blunder [still unexplained as at 2026-10-28T15:45:00Z] made by an Indian cybersecurity company called eMudhra.
In theory, this blunder could have undermined HTTPS (secure HTTP) entirely.
That’s the encrypted flavor of HTTP that we rely on for privacy and security all day, every day – while browsing, when typing passwords into online services, and even during vital product updates that download patches for the latest security holes.
Fortunately, browser makers including Mozilla, Google, Microsoft and others were able to fix the problem promptly and automatically, by telling their browsers to stop trusting at-risk security attestations issued by eMudhra.
In a nutshell, here’s what happened, though first we need to go back a few years.
In 2022, eMudhra was admitted to an elite cohort of web security companies, of which there are only about 100 around the world, that are trusted as root certificate authorities (root CAs) by all major browsers, and by any web-based apps, including product auto-update tools, that rely on the Mozilla Root Store.
The Root Store is a list of web certificates that belong to CAs that are considered trusted and reliable enough to verify and vouch for, by means of a digital signature, any certificate created by any website operator anywhere in the world.
Not all root CAs will sign certificates for anybody in any country, although many do, but any certificate that any root CA does sign is intended to be trusted by everybody.
Mozilla’s list is published for free under the well-known name certdata.txt, and almost all vendors – whether they realize this or not – make use of it as their own “source of truth” for online cryptographic trust.
(You can also access a browsable list of root CAs, if you like, with embedded links to download each CA’s trusted certificate files.)
The Firefox and Chromium browsers rely on this curated list, and most Linux distros include a regularly-updated package that consists of all currently-accepted root certificates saved in file form.
Some apps, scripting languages, and other tools include their own copy of the certificate data from certdata.txt; some hook up with the certificates managed by the operating system itself; others use a mix of both approaches.
In one sentence, if Mozilla’s list says a CA’s root certificate is trusted to vouch for other sites and services, you should assume that your computer or phone, and all the apps on it, will trust that root certificate automatically.
Rather than using their directly-trusted-by-the-browser root certificates to sign every user’s certificate directly, CA typically use a two-level model.
They use a root certificate to sign shorter-lived intermediate certificates, and then use those intermediates to sign certificates for end users and companies.
This creates a chain of trust from a final certificate, or leaf (because it’s at the end of a branch), all the way to a root CA’s certificate, and from there to the browser itself.
In other words, attackers who could crack the private key associated with any root certificate of any trusted CA, or of any intermediate certificate vouched for by a root CA, could create valid, signed certificates that would fraudulently vouch for any internet domain they liked.
That’s because the private key corresponding to the public key in a CA certificate is the only secret information needed to issue digital signatures in the name of the owner of that certificate.
Having a copy of a CA’s private key in 2026 is like having a perfect facsimile of the King’s signet ring in 1526 or 1326, because it allows you to stamp what looks exactly like an official seal of approval onto your own bogus material.
Sadly, back in April 2025, eMudhra created eight virtual signet rings, in the form of intermediate certificates similar to this one:
-----BEGIN CERTIFICATE----- MIIDWzCCAuCgAwIBAgIPeBiTP4+FtGGaKzX7qD0KMAoGCCqGSM49BAMDMFUxCzAJ BgNVBAYTAklOMSUwIwYDVQQKDBxlTXVkaHJhIFRlY2hub2xvZ2llcyBMaW1pdGVk . . . YEELsNKqzUtH2dVFi4BaKFdyrr/6G1dIWp8KAVgsw2/u4lyyboUDaC9jDvICMQC9 HTxku84tNX9dmHOtH7aC2Nu/JM0jTf6KjZAvovCJzzv1IFWSZpVLZibynMLXOrM= -----END CERTIFICATE-----
This format is known as PEM (originally derived from the privacy enhanced mail), and it consists of a series of data fields in binary form using a cumbersome 1980s encoding scheme known as ASN.1, encoded again using base64 to ensure it’s all in plain, printable ASCII text, and then wrapped in BEGIN and END lines to make it easy to spot.
For better or worse, certificates aren’t human-readable in this format, but we can decode the certificate to reveal considerable detail.
Note that the cryptographic key embedded in this certificate uses so-called elliptic curve cryptography, using a standardized configuration known as NIST Curve P-384, also called secp384r1.
The public key is defined by two 384-bit numbers (X and Y below) that constitute a point on this elliptic curve, a concept we’ll dig into in Part 2:
serial_number (in hex): 296926C227A3A1526392B19482A504
issuer: 'C=IN, O=eMudhra Technologies Limited, CN=emSign Root TLS CA - G3'
subject: 'C=US, O=eMudhra Inc, CN=EM OV TLS CA - G3C'
valid_from: 2025-04-30T15:37:41Z
valid_upto: 2040-04-28T18:30:00Z
public_key_algo: NIST Curve P-384 (secp384r1)
public_key_curve_point:
X (384 bits, 48 bytes, in hex) =
138251CD52AC9298C1C8AAD977321DEB
97E709BD0B4CA0ACA55DC8AD51DCFC9D
1589A1597E3A5120E1EFD631C63E1835
Y (384 bits, 48 bytes, in hex) =
CACAE29869A62E1631E8A28181AB5661
6DC45D918ABC09F3AB0E63CF792AA4DC
ED7387BE37BBA569549F1C02B270ED67
key_usage: sign_certs,
sign_cert revocation_lists
certificate_authority: true
The private key that matches a Curve P-384 public key is a 384-bit (48-byte) number.
We’ll describe in Part 2 why the private key is a single number, rather than an (X,Y) point of two 384-bit values like the public key, but the important thing here is that the private key is chosen first, and it’s supposed to be entirely random.
The values allowed for a Curve P-384 private key are anything from 1 to nearly-but-not-quite 2384, giving a truly enormous number of choices – far, far more, in fact, than the number of quarks in the observable universe.
So, although any private key is as likely as any other, you’d expect to see numbers with unpredictable bit patterns when converted into binary (base 2) notation, as in these examples:
1000111000011011..[352 random bits]..1010101011110101 0000010011111101..[352 random bits]..1111100011101100 1000111000011011..[352 random bits]..1010101011110101
There are a few places here where several 0 or 1 bits appear in a row, but no obvious patterns or extremely long runs.
The calculations needed to start with a P-384 private key to generate its matching public key can be done in moments, typically within just 10 to 100 microseconds on a commodity laptop.
But, in theory at least, there’s no fast way to go backwards from the public key, in the form of the (X,Y) point shown above, to its private key.
Working out the public key from the private key takes, loosely speaking, an amount of time proportional to the number of bits in the key (384 in this case).
Going the other way, however, takes an amount of time proportional to 2 to the power of the number of bits (a whopping 2384 here), meaning that it takes exponentially longer as the key size increases.
Indeed, this extreme computational asymmetry is why the mathematics of elliptic curves provides a useful starting point for public-key cryptography , and that’s one of the things we’ll be explaining, rather than taking for granted, in Part 2.
(It’s also one of the reasons why public-key cryptography is sometimes called asymmetric encryption.)
Simply put, “cracking” P-384 elliptic curve private keys means trying the values 1, 2, 3, and so on in turn, to see which numbers generate one of the public keys you want to match.
You need to go all the way to the maximum permissible private key value for this curve, which just happens to be (take a deep breath if you plan to say it aloud!): 39,
You could, if you wanted, try the numbers in reverse, or in some other randomized order, but for arithmetical reasons that will emerge in Part 2, it’s hundreds of times faster to do this sort of brute-force attack in strict numeric sequence, starting from 1.
As it happens, having a go at cracking trusted elliptic curve keys is exactly what a security researcher going by “Wayne” decided to do recently, to see if any trusted CA keys had statistically unlikely private keys.
Although these private keys shouldn’t be crackable, and it ought to be pointless to try, perhaps some of them were generated by a buggy application?
Perhaps some relied on a broken random generator, and could conceivably be cracked in months or weeks, instead of in eons or millennia?
How else to know, except by trying?
And, would you believe it, Wayne hit the jackpot with the eight blunderous eMudhra intermediate certificates mentioned above, not merely in the first trillion or billion tries, but within the first 255 goes.
In case you’re wondering, “Why 255?”, that’s because it’s the largest number you can fit into a single byte (it’s 28-1), so if you start counting from 1 instead of 0, you get there in 255 goes.
As unlikely as it sounds, those private keys all had their first 47 bytes set to zero, effectively making them 8-bit keys.
One of the keys, in fact, had the much-joked-about value 4 (100 in binary), meaning that it can quite reasonably be described as a 3-bit key, as seen here:
Rogue private keys generated and used by eMudhra: 0000000000000000..[352 zeros]..0000000000000100 (3-bit key) 0000000000000000..[352 zeros]..0000000000111000 (6-bit key) 0000000000000000..[352 zeros]..0000000001000010 (7-bit key) 0000000000000000..[352 zeros]..0000000001110011 (7-bit key) 0000000000000000..[352 zeros]..0000000010011011 (8-bit key) 0000000000000000..[352 zeros]..0000000010011100 (8-bit key) 0000000000000000..[352 zeros]..0000000011100110 (8-bit key) 0000000000000000..[352 zeros]..0000000011101101 (8-bit key)
To be clear, any specific key value is as likely as any other, but ending up with eight 384-bit keys that all have their first 376 bits set to zero is a bit like tossing a coin and ending up with heads 376 times in a row․․․
․․․eight times in a row.
There’s no law of physics that prevents it from happening (except, perhaps, for getting a sore thumb tossing the coin 376×8 times and being unable to finish), but it would be very, very safe indeed to bet against it.
The problem here is that once you know the private key that goes with the public key in one of eMudhra’s trusted intermediate certificates, you can put that public-private keypair into a private keyfile of your own.
That reconstructed private keyfile provides you with the same dramatic outcome as breaking into eMudhra’s network, finding their copy of the private key, and stealing it – except, of course, that there would be no trace of any break-in that anyone could ever notice and act upon.
As cryptographic blunders go, that’s up there with the worst of them.
Fortunately, you shouldn’t need to do anything to protect your browsing, because either or both of your operating system and your browser should have revoked their trust in the broken intermediate certificates even before this news broke.
This was achieved using online certificate revocations that happen automatically as you browse.
Mozilla’s Root Store list has also explicitly removed the eMudhra root certificate files that vouch for the broken intermediates, so that software that doesn’t check at runtime for revoked intermediate certificates, but relies on an up-to-date static list of roots instead, will no longer trust those intermediates.
If you have a set of system-wide root certificate files, the certificate files that were removed when this story broke were:
Unfortunately, there are many official places (and any number of unofficial places) where packaged copies of trusted root certificates may end up, and different apps may look in some or many of these, and use the first set of certificates they find.
If you run or build software that directly relies on a static list of root certificate files generated from Mozilla’s Root Store list, you may need (or want) to check that the list of root certificates trusted by that software is up to date.
This is most relevant on hardware devices that don’t get updated frequently, or if you’re creating software with a build system that packages a static set of trusted certificates into the installable packages that you release.
(Don’t forget to join us for Part 2, where we’ll dig into the mathematics of elliptic curves, and how it was undermined in this incident․․․)
FINDING STATIC CERTIFICATE BUNDLES
Some bundles consist of a separate file for each trusted root certificate; other bundles consist of a single file containing all the certificates.
Go programs built for Unix-like systems (which covers many IoT and embedded devices) typically look in numerous places, choosing the first bunch of certificates they find, including:
All-in-one certificate files: /etc/ssl/ca-bundle.pem /etc/ssl/cert.pem /etc/ssl/certs/ca-certificates.crt /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem /etc/pki/tls/cacert.pem /etc/pki/tls/certs/ca-bundle.crt /etc/openssl/certs/ca-certificates.crt /usr/local/etc/ssl/cert.pem /usr/local/share/certs/ca-root-nss.crt Directories (all files loaded): /etc/ssl/certs/* /etc/pki/tls/certs/* /etc/openssl/certs/* /usr/local/share/certs/*
Apple’s macOS includes an all-in-one certificate file that some command-line software uses, instead of going through the operating system itself:
/etc/ssl/cert.pem
Python’s certifi package includes its own all-in-one certificate file called cacert.pem, which may appear multiple times depending on how many Python versions are installed, in version-specific directories such as:
/usr/lib/pythonX.YY/site-packages/certifi /usr/lib64/pythonX.YY/site-packages/certifi /home/USERNAME/.local/lib/pythonX.YY/site-packages/certifi /home/USERNAME/.local/lib64/pythonX.YY/site-packages/certifi
Ask how SolCyber can help you do cybersecurity in the most human-friendly way. Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit you or your business!
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
Ransomware attacks have changed significantly in recent years, leaving every company vulnerable.
Bad news for the crooks, and even worse news for their victims.
If HTTPS provides true end-to-end encryption, how do web firewalls crack into your network traffic? And what stops cybercriminals doing the same thing?
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
