zimmerfrei

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

As mentioned a few days ago, this post mainly covers a gpg problem not a PGP problem.

I recommend people to spend some time and try out sequoia (sq) [0][1], which is a sane, clean room re-implementation of OpenPGP in Rust. For crypto, it uses the backend you prefer (including openssl, no more ligcrypt!) and it isn't just a CLI application but also as a library you can invoke from many other languages.

It does signing and/or encryption, for modern crypto including AEAD, Argon2, PQC.

Sure, it still implements OpenPGP/RFC 9580 (which is not the ideal format most people would define from scratch today) but it throws away the dirty water (SHA1, old cruft) while keeping the baby (interoperability, the fine bits).

[0] https://sequoia-pgp.org/

[1] https://archive.fosdem.org/2025/events/attachments/fosdem-20...

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.

Yes, there are methods to combine multiple, different key exchange algorithms so that you need to break all, like in:

https://datatracker.ietf.org/doc/rfc9370/

https://datatracker.ietf.org/doc/draft-ounsworth-cfrg-kem-co...

https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/01...

For other security mechanisms, like PKI, things are more complicated (and inefficient).

And one can argue that even if in theory the above gives you better security margin, the whole system becomes more complicated, and it may be practically less secure because of the additional moving parts. That is why there is no unanimous consensus: agencies in Europe recommend it, but the NSA does not.

Finally, note that the the 3rd standard (SLH-DSA), is PQC but it is based on old and well-understood standards (SHA2/SHA3), so it can arguably be used by itself.

I like it, because it is indeed nice to have a NIST-backed construction.

But at the same time, it is disappointing that you get locked out of several niceties of NIST KDFs, such as label and context. I get that they are sacrificed to minimize the number of AES calls, but still I would prioritize strong cryptographic separation over just a few saved AES calls, especially for messages longer than a few hundred bytes.

Finally, *random* GCM nonces longer than 96 bits are definitely misunderstood and bring better guarantees than 96 bits nonces [1]. But of course, if you can derive a fresh key for every message, that's definitely to prefer.

[1] https://neilmadden.blog/2024/05/23/galois-counter-mode-and-r...

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.

You assume that boolean operations are constant time, and whether that holds depends on the uarchitecture and how sophisticated the optimization layers are (e.g. nothing prevents the compiler or even the CPU from short-circuiting the OR as soon as the first XOR is non-zero).

Computing a MAC of the two input values under a once-off random key is actually much stronger.

As a matter of that, this highlights that the goal is to lower the SNR for the attacker, and constant time computation is only one of the two non-exclusive ways to achieve that, the other being adding sufficient noise to their measurements.

That's still described as a kernel for the TEE (like OPTEE is), it doesn't look like a replacement for Linux, which runs in the REE.

But then, the vast majority of the affected libraries in that page don't use GMP at all, but their own custom implementation (including openssl).

In reality, RSA signing with blinding will make any implementation (including those based on GMP) resistant to side channel attacks, targeted at the private key.

What most of these library tripped over in that case, is the treatment of the plaintext in a side channel-safe way after the private key operation. For instance, just the simple conversion of an integer to a byte string can be targeted.

Certainly Google (and Oracle and AWS):

https://www.marvell.com/company/newsroom/marvell-enables-ent...

More interestingly, Cavium (now Marvell) also designed and manufactured the HSMs which are used by the top cloud providers (such as AWS, GCP, possibly Azure too), to hold the most critical private keys:

https://www.prnewswire.com/news-releases/caviums-liquidsecur...

> The discrete TPM's threat model was never designed to cover you from attackers using oscilloscope to probe your laptop's SPI bus during the boot process for unencrypted data.

This is not really true. All TPMs (or at least since v2.0, but no matter if discrete or not) support encrypted session against passive eavesdroppers. There is also the possibility to protect against MiTM attacks, but that is more complex (since you then need to setup credentials).

See here [0]:

"Encryption sessions are useful for when the path to a TPM is not trused, such as when a TPM is a remote TPM, or when otherwise the path to the TPM is not trusted."

The issue is that the OS / Bootloader does not implement such mechanism.

[0] https://github.com/tpm2dev/tpm.dev.tutorials/blob/master/Int...

> Pixel phones (and all other phones running Tiramisu+) can attest to the full DICE chain's integrity to any app that requests it. This can be done through the KeyStore API.

I do not see this - the KeyStore API available to apps still only returns an attestation as a normal X509 chain anchored into a local key, which is certified by Google. That is not DICE. Actually, there is no mention of DICE at all in any recent Android API docs.

Or it this documented somewhere else?

I also noticed how the TCG manages to promote DICE without noticing it makes their baby TPM 2.0 obsolete.

Alas, TCG seems to have recognized the mistake, so they have recently proposed for the DICE to rely on a separate entity (the DPE) to handle all secrets and cryptographic operations:

https://trustedcomputinggroup.org/wp-content/uploads/TCG-DIC...

"Examples of environments that could be used for a DPE implementation are a secure coprocessor, discrete secure hardware, a Trusted Execution Environment (TEE), a type-1 hypervisor, operating system kernel, or another type of environment isolated with a hardware-backed mode switch."

The DPE re-introduces a whole class of problems (i.e. authentication and secure communications) that the DICE was meant to simplify away in the first place.

That is not really a big improvement, as it just covers the threat of compromise for the CDN and any of proxies, but not of the PiPI infra itself.

That is covered by PEP 480, which is already 9 years old:

https://peps.python.org/pep-0480/

Too bad that PyPI (and pip) effectively killed PGP signatures under control of the developers (therefore truly end to end) even with the simple TOFU model, and without providing an alternative.

> The thread already indicated that this was fixed and waiting for the next release

Making a release is work too, so the response looks OK to me.

And why exactly should pypi implement it?

Pypi should just be the organized repository of packages, with only some limited assurance over their authenticity. That is, pypi should just let authors upload signatures and metadata.

Something else, something to plug into pip (taking into account also the bootstrap problem), should be responsible for validating the signatures and providing assurance over identities.

People that just want TOFU will use that one plugin. People that trust Microsoft will use the github plugin. People that trust pypi also for identity, will use maybe what you will write when you have time for it. Maybe a popular plugin will allow people to choose many IdPs. Over time, the community will converge and that may be adopted as de facto standard.

But your choice of removing PGP signatures (as on type of signature) is now making that impossible, and you intend to decide in the future for others what the only blessed verification mechanism is (also, with no indication of when that will happen).

The point is that they don't remain the same. Assuming that they do is an operational error.

How many projects are signing each release with a different PGP key each time? And what are the odds that such projects will actually correct their practices as soon as pip implements key verification and make the problems more visible? A lot I guess?

It seems a lot of assumptions are being made...

But it is a self-fulfilling prophecy: the more you hide, hamper, and cripple the signature metadata, the more people will misuse it (without knowing it), which leads to these articles that argue for more crippling because people are misusing it.

The elephant in the room remains that pypi is a big target, and even though I highly appreciate the work done by maintainers (mostly volounteers?) I have a hard time believing they will always be able to keep skilled attackers away from its infra.

> but I don't think you actually want this: lots of large packages have multiple release managers (and contributors who come and go); you don't want to manually resolve each new human identity that appears for a package distribution.

Nope, you assume wrong. That's exactly what I (also) want, that is, knowing that the *authors* remained the same, whoever they are.

> What most people actually want is a strong cryptographic attestation that the package distribution came from the same source as the thing hosting the source code

Nope, nobody really needs more of that, since that's what's your HTTPS certificate is for.

People *really* want to mitigate the risk of pypi infrastructure getting fully compromised, which is very likely, given how many eggs you keep in the same basket there.

PGP signatures were the last ditch, not very convenient but also not as bad as they are painted. But from now on there will be not even that very little.

The real question: how can pip still not allow me to verify a downloaded package with a public key of my choice (PGP key or others, the format is irrelevant)?

In most cases, I don't even want to know who the author is, but just be warned if the signing key changed since last time (possibly because pypi has been compromised, which is the elephant in the python ecosystem room).

This minor feature has been blocked for years on ideological basis (and matched to questionable decisions like hiding on purpose the signatures from the pypi UI), on the grounds that keys are not discoverable and not attached to a strong identity (which happens to be an argument close to what this article say).

Just add that possibility, make it opt in, and allow the ecosystem to figure how out solve the key management/trust/identity problem.

Yes, but that will happen also without BootGuard. So what does Bootguard add with respect to physical attacks?

However, all UEFI implementations (on PCs at least) allow anybody with physical access to disable Secure Boot, the classic method of just popping the button battery remaining valid to these days.

So, isn't this firmware protection with BootGuard only really meant to prevent rootkits from getting persistence?

PS: thanks for all the blog posts you share on the matter! they are really golden

A GCM software implementation can be simple, fast, or secure against side-channel attacks: you can only pick two.

OCB (RFC7253) is indeed much simpler and it really deserves more popularity.

"Small cut" was 30% in my last experience.