How many more amateur attempts did these layers thwart? Did its creators collect enough revenue before the crack was produced?

I suppose uncrackable software, in the sense of e.g. license protection, cannot exist. Software is completely beholden to hardware, and known hardware can be arbitrarily emulated, and there's nowhere to hide any tamper-resistant secret bits. Only in a combination with locked-down, uncrackable hardware can properly designed software without critical bugs remain uncrackable; see stuff like yubikeys. Similarly, communication can remain uncrackable as long as the secret bits (like a private key) remain secret.

How was your experience with Xbox? I heard it was rather watertight?

What’s the concern here? The blog post you linked does not really support its claims with evidence.

[1] is supposedly debunked: https://pawisoon.medium.com/debunked-the-truth-about-mediaan...

> the network traffic sent and received by mediaanalysisd was found to be empty and appears to be a bug.

I say "supposedly debunked" because empty traffic doesn't mean there's nothing going on. It could just be a file deemed safe. But then the author said:

> The network call that raised concerns is a bug. Apple has since released macOS 13.2, which has fixed this issue, and the process no longer makes calls to Apple servers

Definitely the word of the day for me.

The Gate of Moria inscription was plaintext. The first person to not try to interpret it as a riddle solved it.

POWER9 had quite a few neat things going on. I think it's unfortunate that it never became mainstream. The switch to closed source firmware in Power10 is also a downer.

The TPM itself can actually be discrete, as long as you have a root-of-trust inside the CPU with a unique secret. Derive a secret from the unique secret and the hash of the initial bootcode the CPU is running like HMAC(UDS, hash(program)) and derive a public/private key pair from that. Now you can just do normal Diffie-Hellman to negotiate encryption keys with the TPM and you're safe from any future interposers.

This matters because for some functionality you really want tamper-resistant persistent storage, for example "delete the disk encryption keys if I enter the wrong password 10 times". Fairly easy to do on a TPM that can be made on a process node that supports flash vs a general CPU where that just isn't an option.

That's assuming you trust the CPU vendor not to have their own interposer.

The logic you're using here is: if PGP is unsafe, all cryptography must be unsafe too? No, that doesn't hold, at all.

Protecting secrets via hardware is always "decorative" in some sense, the question is just how much time+work it takes to extract them (and probability of destroying the secrets/device in the process). (outside of things like QKD)

But for software systems under a software threat model, bug-free implementations are possible, in theory at least.

What article?

In any case, I'm curious to hear your argument for how "PGP has some implementation problems" (unsurprising to most people that have dared to look at its internals even briefly) implies "all non-information-theoretic cryptography is futile".

Except 99% of one-time pad implementations fail in at least one criteria:

* Using CSPRNGs instead of HWRNGs to generate the pads,

* Try to make it usable and share short entropy and reinvent stream ciphers,

* Share that short entropy over Diffie-Hellman RSA,

* Fail to use unconditionally secure message authentication,

* Re-use pads,

* Forget to overwrite pads,

* Fail to distribute pads off-band via sneakernet or dead drops or QKD.

OTP is also usually the first time someone dabbles in creating cryptographic code so the implementations are full of footguns.

What do you mean exactly? Both AMD/Intel have signed firmware, and both support hardware attestation, where they sign what they see with an AMD/Intel key and you can later check that signature. This is the basis of confidential VMs, where not even the machine physical owner can tamper with the VM in an undetectable way.