zimmerfrei

Attestation is not required by the compliance standard for browser CAs (WebTrust) and it is also quite vendor-specific and not very interoperable, so it is not commonly done.

The Root CA must sign requests after authentication, but a "manual" approval is also accepted if done with the appropriate oversight with witnesses (clearly not the case here).

The most likely explanation is that they generated the weak key externally, imported it into the HSM, generated the CSR from it, and finally had Root CA sign it.

A FIPS HSM does not forbid one to import keys into it.

> AMD ROCm is only supported in the rocm branch.

Has anybody tried it? There is a lot of emphasis on MacBook Pro in this thread, but I would like to use it with an AMD Halo Strix with 128GB of unified RAM.

> Nvidia released the first Shield Android TV in 2015

> it took about 18 months to [create] an entirely new security stack [...] Android updates aren’t actually that much work compared to DRM security, and some of its partners weren’t that keen on re-certifying older products.

> In February 2025, Nvidia released Shield Patch 9.2 [...] That was the Tegra X1 [security] bug finally being laid to rest on the 2015 and 2017 Shield boxes.

This is a real engineering marvel. Everybody else would have just given up entirely long time ago. DRM bugs are in most case practically unrecoverable for products that shipped already (and physically in the hands of the adversary). The incentive to tell to consumers "Ditch that product you bought from us 2 years ago, and buy the more recent hardware revision or successor" is extremely strong.

This really feels like a platform that is maintained with pride and love by the nvidia engineering teams (regardless of one's opinion about DRM per se).

I don't think that a 100% anonymous attestation protocol is what most people need and want.

It would be sufficient to be able to freely choose who you trust as proxy for your attestations *and* the ability to modify that choice at any point later (i.e. there should be some interoperability). That can be your Google/Apple/Samsung ecosystem, your local government, a company operating in whatever jurisdiction you are comfortable with, etc.

If you use AEAD, you clearly expect your recipients to use a recent client. Same as if you want to use PQC or any other recent feature.

If your audience is wider, dont use AEAD but make sure to sign the data too.

With respect to the 90's design, yes, it is not pretty and it could be simpler. It is also not broken and not too difficult to understand.

It is not a coincidence that most of the various proposed alternatives to PGP (signal, wormhole, age, minisign, etc) are led by a single golden implementation and neither support nor promote community-driven specifications (e.g., at the IETF).

Over the decades, PGP has already transitioned out of old key formats or old crypto. None of us is expecting to receive messages encrypted with BassOmatic (the original encryption algorithm by Zimmermann) I assume? The process has been slow, arguably way slower than it should have after the advancements in attacks in the past 15 years (and that is exactly the crux behind the schism librepgp/opengpgp). Nonetheless, here we are, pointing at the current gpg as "the" interoperable (yet flawed) standard.

In this age, when implementations are expected (sometimes by law) to be ready to update more quickly, the introduction of new crypto can take into account adoption rates and the specific context one operates in. And still, that happens within the boundaries of a reasonably interoperable protocol.

TLS 1.3 is a case in point - from certain points of view, it has been a total revolution and break with the past. But from many others, it is still remarkably similar to the previous TLS as before, lots of concepts are reused, and it can be deemed as an iteration of the same standard. Nobody is questioning its level of interoperability, and nobody is shocked by the fact that older clients can't connect to a TLS 1.3-only server.

When you encrypt something, you are the one deciding which level of interoperability you want and you can select the crypto primitives matching capabilities you know you recipient reasonably have. I don't see anything special with this: when you run a web service, you also decide if you want to talk to TLS 1.0 clients (hopefully not).

sequoia's defaults are reasonable as far as I remember. It's also bit strange that the post found it defaulted to using AEAD in 2019 when AEAD was standardized only in 2024 with RFC 9580.

But the elephant in the room is that gpg famously decided to NOT adopt RFC 9580 (which Sequoia and Proton do support) and stick to a variant of the older RFC (LibrePGP), officially because the changes to the crypto were seen as too "ground-breaking".

This is the right answer.

The problem mostly concerns the oldest parts of PGP (the protocol), which gpg (the implementation) doesn't want or cannot get rid of.

Let's assume that you have a simple XOR between two registers.

If the CPU can pre-label a register as having no bits set (and they can or speculate on it), during scheduling, it could theoretically simply drop the XOR, transfer or rename the relevant register which may lead to a tiny but different timing that can be measured and exploited.

That is just one simple counter-example that shows how the assumptions you present are not necessarily valid on modern complex CPUs. Many more are examples are possible, which is of course not to say that they are implemented today. But they could be implemented in the future (without us knowing, and again, both ARM and Intel are explicit on that), therefore the security of a security-sensitive piece of code should not solely rely on that.

Your argument boils down to "all hardware implementations so far in history never optimized word boolean operations so future implementations will keep doing so".

I think that is just an assumption and I would not take that risk for high security applications, unless for specific CPU models where the behavior is measured in practice (certainly not by just auditing the assembly, which is by itself already too high-level). After all, never in history we had such a level of sophistication.

Right now, all zero register values can lead to speed gains, so they could be obversable. But both ARM and Intel latest ISA have introduced flags that permit the future CPUs to perform operations with data-dependent timing. Boolean operations are officially marked as potentially affected by that flag.