this post was submitted on 14 Jun 2025
619 points (97.8% liked)
Greentext
6628 readers
1927 users here now
This is a place to share greentexts and witness the confounding life of Anon. If you're new to the Greentext community, think of it as a sort of zoo with Anon as the main attraction.
Be warned:
- Anon is often crazy.
- Anon is often depressed.
- Anon frequently shares thoughts that are immature, offensive, or incomprehensible.
If you find yourself getting angry (or god forbid, agreeing) with something Anon has said, you might be doing it wrong.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Video evidence is relatively easy to fix, you just need camera ICs to cryptographically sign their outputs. If the image/video is tampered with (or even re-encoded) the signature won't match. As the private key is (hopefully!) stored securely in the hardware IC taking the photo/video, any generated images or videos can't be signed by such a private key.
So whatever way the camera output is being signed, what's stopping you from signing an altered video with a similar private key and then saying "you can all trust that my video is real because I have the private key for it."
The doubters will have to concede that the video did indeed come from you because it pairs with your key, but why would anyone trust that the key came from the camera step instead of coming from the editing step?
You, the end user, don't have access to your camera's private key. Only the camera IC does. When your phone / SD card first receives the image/video it's already been signed by the hardware.
so you want the hardware to be significantly more opaque and almost impossible for new manufacturers to compete?
It's pretty standard practise these days to have some form of secure enclave on an SoC - Arm's TrustZone, Intel's SGX, AMD's SME/SEV. This wouldn't be any different. Many camera ICs are already using an Arm CPU internally already.