XMPP Service Operators - 2026-01-20

I don't like TLSv1.3 because it forces the implementation of AES128 when machines are perfectly capable of of doing 256

isn't there research evidence that AES256 may have lower security than AES128?

There's no reason to do bare-minimum security when bumping up the bits adds extra safety margin against potential future attacks for no noticable latency. In fact, a lot of hardware implementations of AES can do 256 faster.

> isn't there research evidence that AES256 may have lower security than AES128? I don't think so. ↺

talking about AES 256 in Galois Counter Mode with a 12 byte IV

AES in Counter Modes is used as a generator for a stream that is XORed with the actual data. I would consider its block size an implementation detail.

The IV is irrelevant in TLS as long as you don't reuse it for multiple TLS cells

I wonder, if there were AES512 or 1024 if some people then immediately would consider everything lower like AES256 as too weak.

> isn't there research evidence that AES256 may have lower security than AES128? By practical definitions it wouldn't be "lower security", but there are indeed some theoretical attacks published against AES-256 (and 192 IIRC) that aren't applicable to 128 due to differences beyond the numbers. My understanding from last time I looked into it is that those attacks are (1) better than brute force but still way too hard to pull off in practice, (2) negated by the way AES is used in most applications.

https://eprint.iacr.org/2009/374 https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

So nothing to worry about, but indeed algorithms with bigger numbers are not automatically better

well thats what happened to RSA... just bump the number and call it a day :p

MattJ, right, that.

Triple AES to make it safer

> I don't like TLSv1.3 because it forces the implementation of AES128 when machines are perfectly capable of of doing 256 tom: to be clear, you dislike 1 theoretical weakness that very likely isn't a weakness, and therefore choose instead to go with many known flaws/weaknesses/broken security in TLS 1.2 ? seems a bit off ↺

read these and see if you think keeping TLS 1.2 enabled increases or decreases your security: https://web.archive.org/web/20250804151857/https://www.mitls.org/pages/attacks/3SHAKE (enables MITM to silently break channel binding in XMPP) https://web.archive.org/web/20250406160338/https://www.mitls.org/pages/attacks/SLOTH https://web.archive.org/web/20250401021020/https://www.mitls.org/pages/attacks/Logjam and really all the rest linked there, known broken for just over a decade now

so like TLS is about both encryption and authentication right? If you have rock solid encryption such that no observer could possibly decrypt, but you are encrypting it to the attacker/MITM that's completely useless. And TLS 1.3 fixes a bunch of those holes allowing you to accidentally encrypt to the attacker that TLS 1.2 has wide open. Stop using TLS 1.2. Thanks for coming to my Ted Talk.

Did you swallow a crypto textbook or something

lol

TLS1.2 can be made perfectly secure if you use it right, it is a more flexible protocol. The benefits exclusive to 1.3 like 0RTT and session tickets have vulnerabilities when used in certain contexts anyways and have to be disabled, with anything removing knobs isn't a substitute for education. My gripe with TLS1.3 is the spec says that AES128 "MUST" be implemented not 'SHOULD', and if you notch out that particular ciphersuite but not others your no longer in conformance with the spec whereas with TLSv1.2 you can notch out any ciphersuite and remain conformant. There's nothing wrong with doing more then the bare minimum of safety standards. The bare minimum is just that, that bare minimum and just like electrical codes these rules are usually written in blood. It wasn't even that long ago SHA1 was considered ""secure"" and the numerous 802.11 bare minimum Wireless security standards that keep getting cracked. I'd like to keep my secrets until they are no longer relevant, say 50 years. That includes a threat model of someone recording to disk all the traffic so that it can be expoited at a later date *cough cough Utah datacenter cough literally all internet traffic in Egypt cough* Also with the coming relevance and advancements of Quantom Computing, the big tech companies buying up 80% of of the world's supply of DRAM at a single time, and the NSA's own reccomendations for internal configuration of cryptosystems and security appliances (which is publiclly available, except for the Post-Quantom reccomendations which is still going to required a successful FOIA) and how our cryptosystems were broken in the past It's reasonable to expect and plan for zero days in the future that may be able to weaken the effective cryptography to a few bits. Especially with quantom computing and it's relevance to the diffie hellman key exchange systems and the elliptic curve varients, it may be possible for a quantom computer to weaken a DH to enough where a classical computer with ungodly amounts of DRAM (which will soon be available to rent by the hour via stargate and AWS);

tom: you can't make TLS 1.2 secure, that's the entire reason 1.3 exists, no negotiation fixes the truncated hashes https://web.archive.org/web/20250406160338/https://www.mitls.org/pages/attacks/SLOTH *technically* if both sides ensure the extended master secret extension is negotiatiated that fixes https://web.archive.org/web/20250804151857/https://www.mitls.org/pages/attacks/3SHAKE & XMPP channel binding but guess how many clients & servers do this check? I know because I've looked into them and it's 0, most TLS libraries don't even expose enough data to let you do this check

TLSv1.4 soon probably.

or TLSv1.3.1

I mean 1.2 lasted 10 years and 1.3 8 years so far so maybe soon :P but I haven't heard anything about that yet

Not great, Not terrible.