A while back I helped a friend (read: dumped a bunch of compute power into it) brute force the SSL keys for Sega's "Phantasy Star Online" Dreamcast game.

They used a similar kind of custom (and flawed) TLS implementation in their game(s) which allowed signing new certificates after brute forcing.

The benefit to this is that users can now play these games without needing to burn a new CD with either the SSL certs swapped, or the code patched to dummy out the checks. A "retail CD" will simply work with private servers now.

I've also been on the other side of the fence, building a "retro internet" service [1] has meant trying to implement ancient SSL/TLS services for things and people that want to use them on the network.

Getting modern OpenSSL (aka what ships in Debian) to even accept these ciphers, let alone keys that short is an uphill battle. Understandably, they're disabled by default and (in Debian at least) the cipher support isn't even compiled into the binary! This requires building a custom OpenSSL to build Nginx against to serve ancient SSL.

Presumably for the OP this kind of work was either outside of their realm of knowledge, or simply "easier" to outsource to the slop machine. Though I hope the machine they're running their demo TLS implementation on is separated completely from their own network. Rolling your own crypto libraries is always a bad idea [2] and I doubt LLM's have "improved" that

[1] https://www.youtube.com/watch?v=cSJsGNIDjtc

[2] https://soatok.blog/2025/01/31/hell-is-overconfident-develop...

For what it's worth, this comment was better than the article...

When you outsource to the slop machine, you don't have anything interesting to say (usually).