zahllos

In the UK Nominet (the UK domain namr registrar - nic.uk) only permitted 3rd domains - co.uk. org.uk, me.uk. then there were "prove your status" ones such as ltd.uk, plc.uk and ac.uk plus ones like gov.uk, mod.uk, sch.uk, nhs.uk etc.

.uk was opened up relatively recently.

I implemented something similar for my bot defences. If headless chrome is detected you still get the same anubis-style PoW but even if you submit the right answer you get rejected.

I've never done anything "serious" with haskell, just small personal projects. Mostly this is because I've found the ecosystem to be a pain - when I was trying stack stack was the thing to use but from what I can tell ghcup+cabal now work better.

If you push through that you end up with code written in a language people have used for formal proof (seL4 model is Haskell) and deployment wise a binary that +/- libraries you depend on ought to be reasonably portable.

I'm very surprised anyone would want to go the other way. Same ecosystem pain, plus you need to start shipping interpreters or containers, plus the language just doesn't really compare.

Also true. The BOMs though are annoying.

Additional Detail: it is specifically utf-16 little endian when a byte order mark is not used, which is the opposite of the recommended choice of big endian in the RFC.

Worse are the byte order marks required to support both endians that end up in files.

No unfortunately it is not correct. You can supply a different CA to verify client certs against to what is given in server hello. There's no need for them to be related at all.

Critically you probably want to use a custom CA for client certs. The usual implementation logic in servers is "is this cert from the client signed by one I trust?". If that CA is LetsEncrypt say then that's a lot of certificates that will pass that check.

I agree. I wanted a particular tool to support my development. The libraries are well known and understood by people who work in text editors, but this is not my area and I have a busy life. Simply working out what I needed to know produced enough inertia to stop it happening.

I finally made it with Claude. I've been writing code a while so I absolutely didn't let Claude loose and I still refactored stuff by hand as sometimes that was faster than trying to get Claude to do it. I also know what the whole thing does - I read all the diffs it presented.

I wouldn't fully trust it to go off and do its thing unsupervised especially in my areas of speciality. But the scaffolding work like command line arguments - typing all that out was never my passion and I had snippets in my editor for most of it.

Perhaps if your passion is the process of doing that kind of meticulously laying out of each file then I can understand. Although the journey for me is the problem solving. Nothing much excites me about any of the boilerplate parts.

Claude can certainly take a stab at the solution too and is best when it has some kind of test case to match or validation step. To me working out what those are was always the core of the job and without them Claude can make plenty of mistakes.

It's just a tool and I use it in ways to support what I enjoy.

My work situation is way more complicated. Bigcorp organizational dynamics nullify any marginal gain anywhere.

I understand his concern perfectly. What I am saying is that his concern is not mitigated at all by the presence or absence of an IETF standard.

This is going to happen anyway (non hybrid) at least inside USG because that's what NSA want.

I guess that would have been Silverman etc? That's true there was NTRU before reductions were shown. Good call.

Source for this loss of security? I'm aware of the MATZOV work but you make it sound like there's a continuous and steady improvement in attacks and that is not my impression.

Lots of algorithms were broken, but so what? Things like Rainbow and SIKE are not at all based on the hardness of solving lattice problems.

Sure. I'm not American either. I agree, maximum scrutiny is warranted.

The thing is these algorithms have been under discussion for quite some time. If you're not deeply into cryptography it might not appear this way, but these are essentially iterations on many earlier designs and ideas and have been built up cumulatively over time. Overall it doesn't seem there are any major concerns that anyone has identified.

But that's not what we're actually talking about. We're talking about whether creating an IETF RFC for people who want to use solely use ML-KEM is acceptable or not - and given the most famous organization proposing to do this is the US Federal Government it seems bizarre in the extreme to accuse them of backdooring what they actually intend to use for themselves. As I said, though, this does not preclude the rest of the industry having and using hybrid KEMs, which given what cloudflare, google etc are doing we likely will.

Indeed. Dual_EC was a NOBUS backdoor relying on the ECDLP. That's fair.

My point was more that it looked suspicious at the time (why use a trapdoor in a CSPRNG) and at least the possibility of "escrow" was known, as evidenced by the fact that Vanstone (one of the inventors of elliptic curve cryptography) patented said backdoor around 2006.

This suspiciousness simply doesn't apply to ML-KEM, if one ignores one very specific cryptographer.