-mtune says "generate code that is optimised for this architecture" but it doesn't trigger arch specific features.

Whether these are right or not depends on what you are doing. If you are building gentoo on your laptop you should absolutely -mtune=native and -march=native. That's the whole point: you get the most optimised code you can for your hardware.

If you are shipping code for a wide variety of architectures and crucially the method of shipping is binary form then you want to think more about what you might want to support. You could do either: if you're shipping standard software pick a reasonable baseline (check what your distribution uses in its cflags). If however you're shipping compute-intensive software perhaps you load a shared object per CPU family or build your engine in place for best performance. The Intel compiler quite famously optimised per family, included all the copies in the output and selected the worst one on AMD ;) (https://medium.com/codex/fixing-intel-compilers-unfair-cpu-d...)

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

You should be aware there's a 3 day limit to uptime, then PE reboots. You can work around that: https://lsoft.zendesk.com/hc/en-us/articles/360011128377-I-n...

The other thing to tell you is that this is not a live version of windows with all the features of the full desktop. It is the windows that runs the windows installer application, so enough windows to do that and no more.

I would personally recommend linux instead.

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

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.

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.

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.

If you want a better analogy, we have a seatbelt for cars right now. It turns out when you steal plutonium and hot-rod your DeLorean into a time machine, these seatbelts don't quite cut the mustard. So we need a new kind of seatbelt. We design one that should be as good for the school run as it is for time travel to 1955.

We think we've done it but even after extensive testing we're not quite sure. So the debate is whether to put on two seatbelts (one traditional one we know works for traditional driving, and one that should be good for both) or if we can just use the new one on the school run and for going to 1955.

We are nowhere near DeLoreans that can travel to 1955 either.

ML-KEM/ML-DSA were adapted into standards by NIST, but I don't think a single American was involved in the actual initial design.

There might be some weakness the NSA knows about that the rest of us don't, but the fact they're going ahead and recommending these be used for US government systems suggests they're fine with it. Unless they want to risk this vulnerability also being discovered by China/Russia and used to read large portions of USG internet traffic. In their position I would not be confident that if I was aware of a vulnerability it would remain secret, although I am not a US Citizen or even resident, and never have been.

Obviously the standard will be used. As I said in a sibling comment, the US Government fully intends to do this whether the IETF makes a standard or not.

In this context, it is largely irrelevant whether the IETF chooses or not to have a single-standard draft. There's a code point from IANA to do this in TLS already and it will happen for US Government systems.

I'd also add that personally I consider NIST P-Curves to be absolutely fine crypto. Complete formula exist, so it's possible to have failure-free ops, although point-on-curve needs to be checked. They don't come with the small-order subgroup problem of any Montgomery curve. ECDSA isn't great alone, the hedged variants from RFC 6979 and later drafts should be used.

Since ML-KEM is key exchange, X25519 is very widely used in TLS unless you need to turn it off for FIPS. For the certificate side, the actual WebPKI, I'm going to say RSA wins out (still) (I think).

Here's the thing. The existence of a standard does not mean we need to use it for most of the internet. There will also be hybrid standards, and most of the rest of us can simply ignore the existence of ML-KEM -only. However, NSA's CNSA 2.0 (commercial cryptography you can sell to the US Federal Government) does not envisage using hybrid schemes. So there's some sense in having a standard for that purpose. Better developed through the IETF than forced on browser vendors directly by the US, I think. There was rough consensus to do this. Should we have a single-cipher kex standard for HQC too? I'd argue yes, and no the NSA don't propose to use it (unless they updated CNSA).

The requirement of the NIST competition is that all standardized algorithms are both classical and PQ-resistant. Some have said in this thread that lattice crypto is relatively new, but it actually has quite some history, going back to Atjai in '97. If you want paranoia, there's always code theory based schemes going back to around '75. We don't know what we don't know, which is why there's HQC (code based) waiting on standardisation and an additional on-ramp for signatures, plus the expensive (size and sometimes statefulness) of hash-based options. So there's some argument that single-cipher is fine, and we have a whole set of alternative options.

This particular overreaction appears to be yet another in a long running series of... disagreements with the entire NIST process, including "claims" around the security level of what we then called Kyber, insults to the NIST team's security level estimation in the form of suggesting they can't do basic arithmetic (given we can't factor anything bigger than 15 on a real quantum computer and we simply don't have hardware anywhere near breaking RSA, estimate is exactly what these are) and so on.

I completely agree it would be better to rethink what we want and have markup/code/etc optimised to the task of rendering applications. I don't think it'll happen unfortunately.

Small groups could likewise be supported.

I take the point that for large groups client fan out of the double ratchet doesn't scale. We now have MLS but we didn't. There's also an argument of how can you really keep a secret in an open group of a few thousand people.

But on a small, "personal" level, e2e could absolutely be done. Not doing so is a choice, one that conveniently ends with almost everyone's chats stored on servers somewhere.

I would go so far as to say I bet telegram is a goldmine for TLAs.

This is where you get certified copies should you ever need that for interfacing with foreign governments that want them (the European country I live in very much wants a copy of my birth certificate).

It's not an identity check by any means but a legitimate birth certificate ought to be findable here.

But yes birth cert + utility bill is a very, very weak binding to identity.