Ahhhhhh! Thank you for mentioning Precordial catch syndrome. I read about it some time ago, and experienced it several times, and then forgot what it was called. Even with the help of LLMs I was unable to re-discover the name of it.
This also lets them clamp down more on youtube-downloader tools. When they rely on the TV's own browser engine, the client fingerprints can vary a lot between devices and firmware updates. This makes "pretend to be a random smart TV" an attractive way of implementing a download tool.
If they control the engine, they control the fingerprint, making it easier for them to detect and harder for 3rd party clients to spoof.
IIRC there are options for exportable and un-exportable private keys when you make one in the secure enclave. Going to guess Tahoe made them un-exportable by default.
There is no way to export data out of secure enclave. You cannot write arbitrary data to secure enclave, as well as read it out.
What happen though is the ability to encrypt the data with secure enclave, store it on our own. When migrating, we decrypt with secure enclave, get back original data and re-encryp on the new device.
As far as I know, you have never been able to import or export keys from the Secure Enclave. It’s more likely that previously keys were stored in the keychain and now they are generated in the SE by default.
Yes you can make private keys that are encrypted by the secure enclave, rather than stored inside it. The "sc_auth" tool on macos has a "ssh-exportable" variant
Hi, I wrote that note by hand; I didn't use Claude. The hypotheses were based on the fact that other emulations used different paths to reach the playback device. For example, I analyzed Rockbox to see how they managed to play music on this chip. I did use Claude and Gemini to investigate and create the emulator code
I think one of us missed the sarcasm. Lots of people post compiled binaries to git, so you can't really use that as a "you shouldn't forget to mention LLM use because you shouldn't submit compiled binaries" because lots of people do it in order to use it as a distribution channel rather than requiring users to compile it themselves or requiring the author(s) to host the binaries elsewhere.
> we sign a perceptual hash (pHash) of the image rather than an exact pixel checksum
Perceptual hashes are non-cryptographic. There are certainly collision attacks, but what about preimages? A preimage would completely break this scheme.
Yep, that breaks this scheme, making it useless. But it's far from the only thing making it useless, and the github page even explicitly lists those:
- "Small content edits slip under the threshold. [...] A localised edit covering ~15%x20% of the frame [...] passes as authentic" - this is the worst part. 15%x20% is huge, for example enough to change the face of the person or the book/text on the image.
- "Cropping is not survivable, at any amount" - given the purported reason for perceptual hashing is surviving light editing, it's pretty disappointing that one of the most common light editing operation is not supported.
Oh, and the whole "cryptographic chip" angle is absolutely bogus from the security perspective. OK, attacker can't extract the private key from chip. But they can simply connect the chip to a different device and have it sign anything! Given that the attacker in this model is device owner, this is absolutely trivial.
Considering child comment, I agree it's not great. That being said, would a bit-hash have worked? How many users are capable of sending bit-perfect images to someone else? I don't expect more than 5% of people to know...
Hi, I'm the author of the above. I also got a Sony A7 IV camera a few days ago. I already have a root shell on it. Although that wasn't even required to break Sony's C2PA implementation...
Simpler than that, you can just talk to the cryptography IC yourself and ask it to sign stuff. No need for an FPGA, just an arduino. Given the datasheet I imagine any LLM from the last year should be able to oneshot it.
reply