r00ty

Yep wildlife. The only crash I’ve ever had, happened after a fox ran out in front of the car. Your own driving is just one part of the equation.

Just testing the big red button is still working. Nothing to see here, no I mean literally nothing to see here!

That image crops out the best caps of all. The “Trump 2028” caps. What a world we live in.

It’s probably from the era when everyone had a Facebook account. In the modern era, I am sure a Tik-tok (is that what all the kids are doing now?) video would suffice.

Maybe they can check people like me that deleted on their reddit posts and comments… See if the AI can see all that “removed” content :P

This is the way.

This already happens right now. If you have 22 open, your firewall is getting hammered with bots trying to get in, regardless of what cipher you’re using, trying to exploit known weaknesses.

I know, except they’re only ever trying lame user/password pairs that only an idiot would have on their luggage. Same as on asterisk and the bots trying to exploit decades old exploits on wordpress etc. Regardless of whether the site you host is even remotely like wordpress.

I’m not sure how you’d achieve this. If you have a mechanism to change cipher modes then there would be part of the codebase and handshake that validates settings in some way, which adds potential attack vector.

Doesn’t need to change the handshake. If the server is mine, and run by me and I decide I was to change say, just the key exchange part of the process. It could be changed without negotiation. I just need to make sure all clients are configured the same way. My point being there wouldn’t be a negotiation. If you try to connect to wireguard on my server, you’d need to have the key exchange setup in the same way, with the same parameters too. Yes, it should be entirely optional and require specific configuration changes on both client and server to achieve. So long as server and client are configured with the same parameters there’s no negotiation to make. The channel can be setup and if the configuration is wrong it just won’t work.

Well, I did think the “security through obscurity” line would come up. But that’s really something that should be reserved for people making their own “triple XOR” crypto implementations closed source and hoping that protects them.

The “obscurity” if it’s the term we want to use here in my use case isn’t hiding using closed source to provide a perception of security. It’s just giving a choice of crypto, but not adding to the protocol with negotiation.

My thinking is this, and we’ll look at say ssh. We can choose between multiple key types and lengths for that. Now let’s say for example ed25519 is compromised (in real terms I think the only likely compromise for any of the ssh key based auth options would be deriving a private key from the public key, so the “scanning” I talk about is a fantasy. But I’m going with it!). For ssh, there will for sure be bots hunting the internet for vulnerable ssh servers very soon after. Automating the process of getting in, installing whatever nefarious tools they want and moving on. But, crucially they will only get those that have used ed25519 for their auth key login. However they might well get every single wireguard vpn.

I’m really just advocating for the same option really. The option to not use the same as everyone else. With no reduction in security for anyone else and no need to negotiate, the onus would entirely be on the operator to ensure the same stack is configured on client and server. Of course with the understanding that using any other stack is at your own risk. E.g. “triple XOR” security might not be the best, for example :P

Oh and as I said, I doubt I would use it. I use wireguard as it is, I like wireguard as it is. But, I feel like having options is not a bad thing, provided the default is the “best” option currently known.

It’s the usual enshittification tactic. Make AI cheap so companies fire tech workers. Keep it cheap long enough that we all have established careers as McDonald’s branch managers, then whack up the prices once they’re locked in.

I only have one problem with this. When they say wireguard being crypto opinionated is a good thing. I am weary to agree with that statement entirely.

While it is good for stability (only one stack to support and get right, and to be secure and efficient) I do wonder about overall and future security. Saying “You must use this specific cipher suite because we think it’s the best” is a bit of a dangerous road to take.

I say this just because Curve 25519 is considered a very secure elliptic curve, to the best of my very limited knowledge on this subject. But we had a certain dual elliptic curve pseudo random number generator was pushed as “best practice” (NIST backed) some time ago, which didn’t turn out so well, even omitting possible conspiracy scenarios, it had known weaknesses even before it was recommended. [1]

Since then I’ve generally not been a huge fan of being given one option as “the right way” when it comes to cryptography. Even if it is the “best” it gives one target to try to find a weakness in, rather than many.

I say all this as a wireguard user, it’s a great, fast and reliable VPN. I just have concerns when the choice of using other algorithms and especially putting my own chosen chain together is taken away. Because it puts the exact same target to break on every one of us, rather than having to work out how to break multiple methods and algorithms and multiple combinations.

[1] https://en.wikipedia.org/wiki/Dual_EC_DRBG

I mean, you say that. But I think there’s money to be made here. If we just create a new name for pasteurisation processes and market it as “that thing” raw milk. Of course with a 200% markup. Free money!