Only RSA uses a function equivalent to encryption when producing signatures, and only when used in one specific scheme. Every other algorithm has a unique signing function.
Natanael
joined 1 year ago
Apple's scrapped on-device CSAM scanning was based on perceptual hashes.
The first collision demo breaking them showed up in hours with images that looked glitched. After just a week the newest demos produced flawless images with collisions against known perceptual hash values.
In theory you could create some ML-ish compact learning algorithm and use the compressed model as a perceptual hash, but I'm not convinced this can be secure enough unless it's allowed to be large enough, as in some % of the original's file size.
Browser controlled modal.
Do not show a checkmark by default! This is why cryptographers kept telling browsers to de-emphasize the lock icon on TLS (HTTPS) websites. You want to display the claimed author and if you're able to verify keypair authenticity too or not.
SHA family and MD5 do not have keys. SHA1 and MD5 are insecure due to structural weaknesses in the algorithm.
Also, 2048 bits apply to RSA asymmetric keypairs, but SHA1 is 160 bits with similarly sized internal state and SHA256 is as the name says 256 bits.
ECC is a public key algorithm which can have 256 bit keys.
Dilithium is indeed a post quantum digital signature algorithm, which would replace ECC and RSA. But you'd use it WITH a SHA256 hash (or SHA3).
Pigeon hole principle says it does for any file substantially longer than the hash value length, but it's going to be hard to find
Public key cryptography would involve signatures, not encryption, here.
It really depends on their motivation. The ones we need to keep out are the ones who enjoy hurting others or don't care at all.
Oof.
They need to implement content addressing for "sidecar" signature files (add a hash) both to prevent malleability and to allow independent caches to serve up the metadata for images of interest.
Also, the whole certificate chain and root of trust issues are still there and completely unaddressed. They really should add various recommendations for default use like not trusting anything by default, only showing a signature exists but treating it unvalidated until the keypair owner has been verified. Accepting a signature just because a CA is involved is terrible, and that being a terrible idea is exactly the whole reason who web browsers dropped support for displaying extended validation certificate metadata (because that extra validation by CAs was still not enough).
And signature verification should be mandatory for every piece, dropping old signatures should not be allowed and metadata which isn't correctly signed shouldn't be displayed. There's even schemes for compressing multiple signatures into one smaller signature blob so you can do this while saving space!
And one last detail, they really should use timestamping via "transparency logs" when publishing photos like this to support the provenance claims. When trusted sources uses timestamping line this before publication then it helps verifying "earliest seen" claims.
Analog hole, just set up the camera in front of a sufficiently high resolution screen.
You have to trust the person who owns the camera.
It needs to focus on showing who published it, not the icon