Horible public key tricks

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...

See also “Everything you Never Wanted to Know about PKI but were Forced to Find Out” by Peter Gutmann:

<http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf>

The linked pdf at https://tom7.org/httpv/httpv.pdf is extremely long but a great read if you enjoyed the article.

On that note: I was always wondering whether you could do stupid CT log tricks.

If I remember correctly, Let's Encrypt lets you go up to a hundred domains per certificate, with 256 characters per domain[1]. If you get a short domain like a.bc and start requesting certificates for its subdomains, you can easily get a few kB of user-controlled data embeddable per certificate. Given LE's rate limits, it should, within a few weeks of easily-automated work, be possible to embed child pornography into a CT log, making it illegal to host and destroying it completely.

You could do something more useful (and less destructive) with this idea; like embedding a separate public key, with the corresponding private key stored offline in an HSM, which could then be used to sign the location of your new domain in case the old one was seized. This would, in a weird and perverted way, add a lot more censorship resistance to DNS than what it natively provides.

You could even use a CT log as a blockchain, with the order of log entries being used for consensus.

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".

Previously:

https://news.ycombinator.com/item?id=50425226 Horrible Public Key Tricks (maurycyz.com) 1 day ago

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.

The AI guestbook is an interesting addition. Does that actually work in weakening crawling LLMs? Which is presumably the idea?

>Nobody checks your private keys

You're implying that they should???

> 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...

I cant get past the title spelling

"... 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

>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!

I don't understand the math. What does plaintext^e mod n actually do?

[flagged]

[dead]

[flagged]