omfg they're ALL FUCKING <255
4 EM OV TLS CA - G3C OV TLS
56 EM EV TLS CA - G3C EV TLS
66 EM OV CS CA - G3B Code signing
115 EM EV TLS CA - G3B EV TLS
155 EM OV TLS CA - G3B OV TLS
156 EM DV TLS CA - G3B DV TLS
230 EM DV TLS CA - G3C DV TLS
237 EM OV CS CA - G3C Code signing
like if you fuck this up on ONE its the most embarrassing thing in the history of TLS but ALL OF THEM with DIFFERENT NUMBERS requires a special kind of brain amputation to be able to come up with
one of them being specifically 4 does seem a bit too on the nose though lmfao
also how the everloving fuck was this not found earlier?
is there nobody that just generated private keys 0-65k, put them into public keys, encoding them with all kinds of encodings and b64 offsets, and.... googling them?????
omfg the plot might thicken it is onto something really funny
there is not yet enough evidence to prove this but there's a really interesting precedent:
eMudhra issued invalid CRL signatures a year ago.
now that we know that they were all super small scalars, we can trivially just generate all private keys in the 0-65535 search space to verify if they indeed used a different key
THAT DOESNT YIELD A SINGLE MATCH.
THE KEY THEY ACCIDENTALLY USED TO SIGN THE CRLS IS NOT A BROKEN ONE.
here's where the conspiracy hat can be put on: what if they accidentally fixed their system to use the proper private keys, which seemed to be sane and was unnoticed because it was right and just quickly rolled back their systems once mozilla pointed it out
it is trying its best to bruteforce the key that was used to sign the "invalid" CRLs as we speak but the search has yielded not a single hint yet.
this theory can't be definitively proven, but it can be definitively proven by reproducing the key, and that doesnt seem to happen with its attempts so far
CALLLLLLLLLLLLLLLLLLLLLLLED ITTTTTTTTTTTTTTTTTTTTTTTTTTT
The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys.
also, this entire ordeal could have been prevented by SIMPLY NOT TESTING IN PROD, and this testing in prod was APPROVED BY EVERYONE INVOLVED
there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
(emphasis mine; source)
eMudhra should, under no circumstances, ever be trusted again
from some rudimentary attempts to verify their story with a soft hsm, it seems to all check out. a plausible story does not mean that there was no malice behind it, but if they fucked around with wrapping, they may genuinely have done this as a honest mistake with many, many preventable steps
it is actually plausible that this was an honest mistake aber den salat haben wir jetzt trotzdem
the only thing really giving it the creeps is this sentence:
d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root
by looking at the notBefore fields, we can see that they are not created in batch:
15:35:09 DV TLS G3C
15:37:41 OV TLS G3C
15:39:31 EV TLS G3C
15:54:08 DV TLS G3B
16:00:12 OV TLS G3B
16:03:31 EV TLS G3B
16:08:27 OV CS G3B
16:38:40 OV CS G3C
so, was this mistake made in a script somewhere, or did a human make this mistake 8 times?
it seems more plausible for this mistake to happen once in its opinion, and not 8 times
Oct 20, 2026, 4:38 PM@49016 Yep
Oct 20, 2026, 4:40 PM@49016 my money is on slop https://repository.emsign.com
Oct 20, 2026, 4:42 PM
Oct 20, 2026, 4:44 PM
@manawyrm @leah @q not gonna lie it has its money on a human work of art
statistically speaking its very unlikely that a llm has private_key = random() & 0xff a lot in its training data, and at least the modern models are all drilled for not wanting to do obviously insecure things even when you explicitly tell them to. the kind of mistakes LLMs make are something like using another public key as a private key and not something as obviously wrong as this
Oct 20, 2026, 4:45 PMOct 20, 2026, 4:52 PMOct 20, 2026, 4:58 PM
Oct 20, 2026, 5:00 PM
Oct 20, 2026, 4:49 PM@49016 emudhra headquarter leaks https://youtube.com/watch?v=u8rdlMUnwho
@49016 at least the powers of two should be in various prepared tables to speed up ECC operations.
The public key format is literally just 0x04 followed by the two coordinates. The only thing you need to do is encode it into x509 and PEM, which is mainly a few static prefixes and base64 encoding
Oct 20, 2026, 5:19 PM@49016 I have a hard time following what any of this means but I know it's really funny on some level and a huge oversight
10/10
Wait no
4/4
@49016 That feels like what one would see if the mistake was encoded in the plan for a signing ceremony and then everyone involved faithfully followed the plan without engaging brain properly
@49016 obviously Clearly a honest mistake?
That is way to obvious e.g. there have been discussion to include such keys in the bad keys project (https://github.com/badkeys/badkeys/issues/38) long before this. Also Kleptography is a somewhat well researched area for those primitives no self respecting person would use that bad of a backdoor
@s1nn105 it will consider believing them once they have a postmortem
@49016 How in the hell do you do this, though??
Why were they dealing with raw private keys anyway, why were they putting them through random weird scripts and then re-importing them into (what seems like) another/their own HSM?
They must've internally known that they fucked up biiiig time when that happened and then didn't report it. No way _THIS_ didn't get catched?!
Is this a government job trying to get TLS root private keys maybe? Either that or a paid off employee.
@49016 It's just a matter of human attention space. Usually people spend their time looking for things that aren't way beyond the stupidity level of what you'd expect someone to actually have done...
@dalias @49016 But misusing non-cryptographic RNGs for key generation is a well-known problem, so you'd think they'd have at least some amount of auditing for hilariously weak keys like this, which can be automated fairly easily...
I expect auditing issued intermediates for this problem will become a thing going forward thanks to this, though I wouldn't expect it to find anything associated with any other public CAs. (I wouldn't be surprised in the slightest if they found a couple more non-CA certificates...)
@49016 well looking at e.g. https://github.com/badkeys/badkeys/issues/38 people (reasonably!!) thought this type of checking was unnecessary
"No, I am not aware of such examples in the wild and I agree that it's very likely that the cost of adding such coverage isn't justified at all."
another 100% quote in hindsight:
"I think 1,2,3 as private keys are far less plausible."
notably leaving open that using 4 as your private key was more plausible.
@49016 Apparently, no xD
@49016 If I had to guess, I bet what happened is the instructions were "generate a 256-bit random number", and somehow that got turned into code that generates a random number in the range 0-256 instead. If it wasn't such an emergency it would be extremely funny.
@49016 To add insult to injury, there's not even one prime number in there!
@christopherkunz @49016 I mean that's barely off vs what you'd expect from the prime number theorem. There's no relationship between primality and secret keys here.
@dalias @christopherkunz @49016 except 156, they're all multiples of two prime numbers
EDIT: I saw a different list than this one in the OPs toot. This list has a number of items that aren't what I said. Sorry for jumping the gun
237 = 3 * 79
230 = 2 * 5 * 23
155 = 5 * 31
115 = 5 * 23
66 = 2 * 3 * 11
65 = 5 * 13
156 = 2 * 2 * 3 * 13
Oct 20, 2026, 4:50 PMOct 20, 2026, 4:50 PM@49016@mastodon.catgirl.cloud i fucking cant
Oct 20, 2026, 5:08 PM@49016 well. At least that probably means nothing was stolen or leaked from their infrastructure. It was always right there out in the open.
Oct 20, 2026, 5:48 PM@49016 the meme ...
Oct 20, 2026, 6:11 PM@49016 how 2 hack vita?
@Li step 1: get it off the internet as soon as possible, there may be a plethora of jailbreaks the coming days
Oct 20, 2026, 6:14 PM@49016 it already jailbroken but im excited for the idea of emulating PSN without any plugins
Oct 20, 2026, 6:42 PMOct 20, 2026, 6:55 PMOct 20, 2026, 6:59 PM@TobiX @49016 https://github.com/LiEnby/psvita-elfs/raw/refs/heads/374-CEX/vs0/data/external/cert/CA_LIST.cer
this is the unmodifed one from 3.74; i cant easily look since my phone tries to load it as a CA to install :/
it might be that just 3.60 is uneffected idk
Oct 20, 2026, 7:32 PM@Li @49016 No "emSign" in there. But it's in https://github.com/SKGleba/iTLS-Enso/blob/master/misc/certs.cer, so it's probably only on iTLS-patched systems...
Oct 20, 2026, 9:29 PM
Wait, what now?
This just keeps getting better(worse) by the moment.
<shakes head in #infosec>
Really glad I retired at the start of this year. Not my circus, not my monkeys, but just "wow"
https://xkcd.com/221/ was prescient indeed.
Oct 20, 2026, 7:08 PM@49016 this post has made it into the citations on the wikipedia page for emudhra lmao en.wikipedia.org/wiki/EMudhra
@49016 sounds like someone got confused and used the primary key.
@49016
Sounds like a bit of a problem... or an 8 bit problem.
I did not favorite your post because I got here at the exact moment.
