This is almost certainly an independent discovery/implementation of the same idea, there's really only one sensible way to do it. There are, of course, several non-sensible ways to do it as well, but...
"the way, to sign a piece of software, you
need to pay an extortive $100/year fee to Apple"
This is the main reason I hate these notarization. And the worst thing is if you want to work on some software that require network extension, you can't even do it without paying apple $99 a year. There are workaround like turning off SIP, but it isn't recommended.
Community approach basically failed in building a "web of trust" with all the PGP/GPG signing parties: both tools were tricky to use, integrating PGP/GPG signing into common tools (like email, word processors, web, but also version control systems like CVS, SVN, bzr, git...) was always lackluster.
LetsEncrypt is a surprising success, but it's still a centralized system running as a non-profit — which means that it's always at risk of not being funded and/or to be under influence of big sponsors. It also came too late, app stores were already centralized.
Obviously, enterprises prefer to be the one to gate the access, so with a situation as it was, they jumped on the opportunity.
Deactivating SIP is not that dangerous if you know what you’re doing. All it does it give back write access to root to some parts of the system.
Obviously, for the commoners, it is definitely not recommended, especially since they usually run random commands from stochastic engines w/o supervision… oh…… engineers do that too now? how in the hell???
> Deactivating SIP is not that dangerous if you know what you’re doing. All it does it give back write access to root to some parts of the system.
To be fair, given the increasingly sneaky cyber attacks these days, the more layers of security between you and root access the better IMHO. Turning off SIP in today's environment is a bit nuts as it is a genuinely sensible security layer.
If you're going to insist on being one of those hardcore "I must be root" people then there's nothing I can say that will satisfy your urge. The same if you are one of those permanent Apple bashers.
However, for the benefit of more sensible people, I will point out:
1. I used the terminology "layered security" twice in my post above
2. By definition if you have a blind hatred of Apple SIP, you must also have a hatred of SELinux or AppArmor or dm-verity or kernel lockdown mode on Linux.
Apple won't even let you pay the fee in some cases. I've been fighting with them trying to figure out why they won't accept my ID verification since March. They keep saying my devices are linked to another Apple Account, but I purchased them all directly from the Apple Store and none of them have ever touched another account, so what the fuck.
All serious attackers are man-in-the-middle attackers (usually by tricking victims into diverting their own traffic, not literally by inserting themselves into the network path). Passive-only attackers went extinct along with the backbone-connected Sun servers that were used to launch those attacks.
I don't so much care about the rest of this analysis, but you can't call an unauthenticated TLS session "secure".
My friend ended up having the URL to a fraudulent version of her online banking start getting auto-completed by her phone’s browser because they’d gotten her to click on some random SMS links a few times.
Website looked identical to the real one so they managed to easily get her one-time-codes. “For security purposes please enter the one-time-code we just sent you.”
No DNS injection. Just auto-complete and a reasonable URL and a convincing <title> in the HTML !
For some reason, getting rid of autocomplete suggestions is harder than getting rid of all other browser data combined. I really don't know why. I've been wishing to clear autocomplete orders of magnitude more often than to clear history or cookies.
Make the web unusable unless you're protected by your "DDOS" protection, offer a free service to solve the problem. Or provide a free service with as little friction to start replacing private/internal networking with, ideally with wide platform support. Or provide some sort of alternative "private" altnet, promising anonymity and access to clearnet via some sort of gateways, specifically for murky stuff.
Or, of course, go high-touch: sell hyper-e2e-encrypted, hardware+software mobile devices directly to crime syndicates, explicitly to keep their traffic safe from prying governmental men-in-the-middle…
So we either expose the key material for inspection (very obviously bad) or we try and brute force how many possible "weak" private keys from the public key to see if they check out?
Note that this is on the order of trillions of useless computations at least per year since almost everyone just uses a CSPRNG or HWRNG available in all modern computers to generate their keys sanely.
Now, for CAs, sure because that is a very small number of certificates. But that's a completely different discussion and also however eMudhra managed to lop off all of the entropy except for the final byte was wildly incompetent and not something a layman would even consider doing.
It's also not the job of the CA to detect you being an idiot. You can go post your private key online after getting your certificate if you so wish, the CA may revoke it if they find out but they're just in the business of helping you secure your communications with others. If you wish for them to actually be insecure... You are silly, but that was always allowed.
FWIW, at at least some of the ACME CAs still willing to sign RSA certificates will make a cursory attempt at brute forcing your private key to make sure you don’t have one very tiny prime and one big one. Tom7 encountered this when he tried to implement the least secure website he could without being flagged by the browser. He ended up using a public modulus with four prime factors instead of 2.
The “4” affair did make me wonder… as a non-expert, I’d always kind of assumed that—with all the ceremony around key ceremonies and all—there might be some way to provably assert the set of techniques used to arrive at the key in the first place. XYZ hardware-signed source of entropy was sampled at DEF time and input into ABC signed chunk of algorithm to arrive at the private key…
In fact I assumed that’s why somebody might explicitly choose “4” as their key: to make it as easily detected as “TK” in a copy edit, or a prefix-designated API key in a repo, or an “@example.com” that slides by into a serious environment.
We really go on a pinky swear across the public CA ecosystem?
You could certainly use zero knowledge proofs to prove some statements about the secret key, like requiring it to be roughly a 1:1 ratio of 0s and 1s and the longest run of the same bit is not significantly larger than log2(n). I think if I were trying to enforce a minimum level of security then I might take that route, requiring that the key passes zero-knowledge proofs of various statistical tests of randomness.
By pigeonhole principle, nearly all numbers have to have a Kolmogrov complexity within some constant of their own length, meaning they are algorithmically random and will by definition pass every statistical test of randomness, so you lose surprisingly few bits entropy per assertion this way.
I am not sure how trillions of computations will occur, simply attempting 0-255 would have found ... all? ... of the eMudhra fuckups. Maybe a few million instructions burnt on a CPU.
And again, you have to actively work to get a "private key" of 0000 ... 0-255. If you want to be stupid it's not really the CA's job to tell you not to be. It's their job to verify your identity. And, again, a CA itself is a totally separate beast where this thinking does not apply. If you want to be secure it's easy to be secure and if you don't want to be... Why should anyone else care? You are only hurting yourself.
"... and the whole system doesn't even work because certificates are issued over plaintext connections, and trusted certificate aurthorities[sic] use very secure keys like "4""
And the CA certificate is "self-signed"
Meanwhile under this "Web PKI" the www user is by default discouraged and/or blocked from using self-signed certificates she herself creates
Someone else decides who she must trust. It's not optional
For example, for a number of years someone else told her she must trust eMudhra
I mean some people can and do remove entries in their trust store. I imagine there's a very near future where someone inclined could have a perfectly serviceable internet experience with nearly all of them removed.
Unfortunately, smart internet users are outnumbered by not so smart users thousands to one. And the not so smart users aren't smart enough to know every time when a website is or isn't trustworthy. So while far from ideal, the world is a much better place since we gave control of the entire internet to a few aristocrats.
Of course that argument got heavily undermined by the existence of Let's Encrypt.
Convert the plaintext to a number using some reversible encoding scheme. For instance, if the plaintext is an ASCII string, then take the ASCII index for each character to get fixed length binary strings, combine those strings.
Take that number, raise it to the power of e, and take the remainder after division of that number by n.
> So, I've always been somewhat annoyed at SSL/TLS. It requires everyone to go through a complex "ACME" dance just to put up a public website. Worse, certificates expire every few months, so it's not a one and done thing: even with automation, maintaining a certificate requires care to ensure the ACME client always has access to DNS records or the web server.
Not actually all that long ago, people faced down the prospect of $1000+/year E.V. Verisign certs that involved faxing legal documents, phone calls, and other probing. Many jumped for joy when LetsEncrypt was finally mature enough for the mainstream. Kids these days don't know how good they've got it...
Yes, but back then SSL/TLS wasn’t a requirement to publish anything on the web. You just needed a domain, and IP and a web server. The minimum bureaucracy you have to do now is much greater.
I suspect there might be something intentional about this. There is a strangely high seeming-typo count in that post (yeild, pivate, relevent, etc). There are typos in the author's other work, but not quite at this density.
You can ask an AI to randomly misspell words too, omit all punctuation or lowercase everything. I don't like the default AI dialect of English either, but at least it's readable while this IMHO just makes you look lazy and stupid. As the old saying goes, "cut off your nose to spite your face".
Previously, Stupid Certificate Tricks (2014): https://news.ycombinator.com/item?id=9516824
This is almost certainly an independent discovery/implementation of the same idea, there's really only one sensible way to do it. There are, of course, several non-sensible ways to do it as well, but...
The linked pdf at https://tom7.org/httpv/httpv.pdf is extremely long but a great read if you enjoyed the article.
Or if you prefer the paper in video form: https://www.youtube.com/watch?v=M1si1y5lvkk
"the way, to sign a piece of software, you need to pay an extortive $100/year fee to Apple"
This is the main reason I hate these notarization. And the worst thing is if you want to work on some software that require network extension, you can't even do it without paying apple $99 a year. There are workaround like turning off SIP, but it isn't recommended.
Community approach basically failed in building a "web of trust" with all the PGP/GPG signing parties: both tools were tricky to use, integrating PGP/GPG signing into common tools (like email, word processors, web, but also version control systems like CVS, SVN, bzr, git...) was always lackluster.
LetsEncrypt is a surprising success, but it's still a centralized system running as a non-profit — which means that it's always at risk of not being funded and/or to be under influence of big sponsors. It also came too late, app stores were already centralized.
Obviously, enterprises prefer to be the one to gate the access, so with a situation as it was, they jumped on the opportunity.
Deactivating SIP is not that dangerous if you know what you’re doing. All it does it give back write access to root to some parts of the system.
Obviously, for the commoners, it is definitely not recommended, especially since they usually run random commands from stochastic engines w/o supervision… oh…… engineers do that too now? how in the hell???
I’m out.
Not every conversation has to be a complaint about AI.
> Deactivating SIP is not that dangerous if you know what you’re doing. All it does it give back write access to root to some parts of the system.
To be fair, given the increasingly sneaky cyber attacks these days, the more layers of security between you and root access the better IMHO. Turning off SIP in today's environment is a bit nuts as it is a genuinely sensible security layer.
Wait until you find out I use passwordless sudo. Surely you can't really believe that every Linux laptop is horribly compromised.
If you're going to insist on being one of those hardcore "I must be root" people then there's nothing I can say that will satisfy your urge. The same if you are one of those permanent Apple bashers.
However, for the benefit of more sensible people, I will point out:
Apple won't even let you pay the fee in some cases. I've been fighting with them trying to figure out why they won't accept my ID verification since March. They keep saying my devices are linked to another Apple Account, but I purchased them all directly from the Apple Store and none of them have ever touched another account, so what the fuck.
Not surprisingly "isn't recommended" by the ones who want you to pay them.
I came here to say the same thing! I’m not sure I have the author’s vehemence, but I enjoyed the read.
Longest ‘paper’ I’ve read in ages, I’m slightly ashamed to admit.
All serious attackers are man-in-the-middle attackers (usually by tricking victims into diverting their own traffic, not literally by inserting themselves into the network path). Passive-only attackers went extinct along with the backbone-connected Sun servers that were used to launch those attacks.
I don't so much care about the rest of this analysis, but you can't call an unauthenticated TLS session "secure".
> usually by tricking victims into diverting their own traffic
What does this mean practically? Getting a VPN profile installed ?
No, the simplest (but far from the only) example is DNS injection.
My friend ended up having the URL to a fraudulent version of her online banking start getting auto-completed by her phone’s browser because they’d gotten her to click on some random SMS links a few times.
Website looked identical to the real one so they managed to easily get her one-time-codes. “For security purposes please enter the one-time-code we just sent you.”
No DNS injection. Just auto-complete and a reasonable URL and a convincing <title> in the HTML !
For some reason, getting rid of autocomplete suggestions is harder than getting rid of all other browser data combined. I really don't know why. I've been wishing to clear autocomplete orders of magnitude more often than to clear history or cookies.
Make the web unusable unless you're protected by your "DDOS" protection, offer a free service to solve the problem. Or provide a free service with as little friction to start replacing private/internal networking with, ideally with wide platform support. Or provide some sort of alternative "private" altnet, promising anonymity and access to clearnet via some sort of gateways, specifically for murky stuff.
Or, of course, go high-touch: sell hyper-e2e-encrypted, hardware+software mobile devices directly to crime syndicates, explicitly to keep their traffic safe from prying governmental men-in-the-middle…
[0] https://en.wikipedia.org/wiki/EncroChat
Tip: select the the ‘tty’ mode prior to digging in.
I’ve never felt a more relaxed feeling (easy on the eyes) while reading any blog in comparison.
Yes! It takes me back to the amber VT-220 terminals at school. I might have the model wrong.
Yes, VT-220. The amber color was so pleasant, and so easy on the eyes.
>Nobody checks your private keys
You're implying that they should???
I suspect private keys should receive a nominal check, that they can't be guessed by smashing the number 4 on a numpad.
So we either expose the key material for inspection (very obviously bad) or we try and brute force how many possible "weak" private keys from the public key to see if they check out?
Note that this is on the order of trillions of useless computations at least per year since almost everyone just uses a CSPRNG or HWRNG available in all modern computers to generate their keys sanely.
Now, for CAs, sure because that is a very small number of certificates. But that's a completely different discussion and also however eMudhra managed to lop off all of the entropy except for the final byte was wildly incompetent and not something a layman would even consider doing.
It's also not the job of the CA to detect you being an idiot. You can go post your private key online after getting your certificate if you so wish, the CA may revoke it if they find out but they're just in the business of helping you secure your communications with others. If you wish for them to actually be insecure... You are silly, but that was always allowed.
FWIW, at at least some of the ACME CAs still willing to sign RSA certificates will make a cursory attempt at brute forcing your private key to make sure you don’t have one very tiny prime and one big one. Tom7 encountered this when he tried to implement the least secure website he could without being flagged by the browser. He ended up using a public modulus with four prime factors instead of 2.
The “4” affair did make me wonder… as a non-expert, I’d always kind of assumed that—with all the ceremony around key ceremonies and all—there might be some way to provably assert the set of techniques used to arrive at the key in the first place. XYZ hardware-signed source of entropy was sampled at DEF time and input into ABC signed chunk of algorithm to arrive at the private key…
In fact I assumed that’s why somebody might explicitly choose “4” as their key: to make it as easily detected as “TK” in a copy edit, or a prefix-designated API key in a repo, or an “@example.com” that slides by into a serious environment.
We really go on a pinky swear across the public CA ecosystem?
You could certainly use zero knowledge proofs to prove some statements about the secret key, like requiring it to be roughly a 1:1 ratio of 0s and 1s and the longest run of the same bit is not significantly larger than log2(n). I think if I were trying to enforce a minimum level of security then I might take that route, requiring that the key passes zero-knowledge proofs of various statistical tests of randomness.
By pigeonhole principle, nearly all numbers have to have a Kolmogrov complexity within some constant of their own length, meaning they are algorithmically random and will by definition pass every statistical test of randomness, so you lose surprisingly few bits entropy per assertion this way.
You're looking for https://www.ietf.org/archive/id/draft-ietf-lamps-csr-attesta.... It's gotten enough renewed attention in the wake of the eMudhra fiasco that I'm reasonably optimistic about it becoming required for intermediates.
I am not sure how trillions of computations will occur, simply attempting 0-255 would have found ... all? ... of the eMudhra fuckups. Maybe a few million instructions burnt on a CPU.
Do you know how many SSL certificates are issued per year? LE issued 10 million per day in 2025. https://letsencrypt.org/2025/12/09/10-years
And again, you have to actively work to get a "private key" of 0000 ... 0-255. If you want to be stupid it's not really the CA's job to tell you not to be. It's their job to verify your identity. And, again, a CA itself is a totally separate beast where this thinking does not apply. If you want to be secure it's easy to be secure and if you don't want to be... Why should anyone else care? You are only hurting yourself.
"... and the whole system doesn't even work because certificates are issued over plaintext connections, and trusted certificate aurthorities[sic] use very secure keys like "4""
And the CA certificate is "self-signed"
Meanwhile under this "Web PKI" the www user is by default discouraged and/or blocked from using self-signed certificates she herself creates
Someone else decides who she must trust. It's not optional
For example, for a number of years someone else told her she must trust eMudhra
I mean some people can and do remove entries in their trust store. I imagine there's a very near future where someone inclined could have a perfectly serviceable internet experience with nearly all of them removed.
Unfortunately, smart internet users are outnumbered by not so smart users thousands to one. And the not so smart users aren't smart enough to know every time when a website is or isn't trustworthy. So while far from ideal, the world is a much better place since we gave control of the entire internet to a few aristocrats.
Of course that argument got heavily undermined by the existence of Let's Encrypt.
Certificates don't tell you whether a site is trustworthy.
I don't understand the math. What does plaintext^e mod n actually do?
Convert the plaintext to a number using some reversible encoding scheme. For instance, if the plaintext is an ASCII string, then take the ASCII index for each character to get fixed length binary strings, combine those strings.
Take that number, raise it to the power of e, and take the remainder after division of that number by n.
> So, I've always been somewhat annoyed at SSL/TLS. It requires everyone to go through a complex "ACME" dance just to put up a public website. Worse, certificates expire every few months, so it's not a one and done thing: even with automation, maintaining a certificate requires care to ensure the ACME client always has access to DNS records or the web server.
Not actually all that long ago, people faced down the prospect of $1000+/year E.V. Verisign certs that involved faxing legal documents, phone calls, and other probing. Many jumped for joy when LetsEncrypt was finally mature enough for the mainstream. Kids these days don't know how good they've got it...
Yes, but back then SSL/TLS wasn’t a requirement to publish anything on the web. You just needed a domain, and IP and a web server. The minimum bureaucracy you have to do now is much greater.
I cant get past the title spelling
Yes. It’s horrible.
I suspect there might be something intentional about this. There is a strangely high seeming-typo count in that post (yeild, pivate, relevent, etc). There are typos in the author's other work, but not quite at this density.
See also: https://maurycyz.com/misc/quality/indicators.html#:~:text=Th...
more: chalange, largly, crytosystems
It's a way to show human authorship I guess... But still, misspelling a headline is pretty shit
You can ask an AI to randomly misspell words too, omit all punctuation or lowercase everything. I don't like the default AI dialect of English either, but at least it's readable while this IMHO just makes you look lazy and stupid. As the old saying goes, "cut off your nose to spite your face".
>the whole system doesn't even work
Yeah, I saw a fire hydrant leaking the other day. Time to tear out all the plumbing, the whole system doesn't even work!