Hacker News new | past | comments | ask | show | jobs | submit login

How could Signal recompress images while retaining end-to-end encryption? Wouldn't any "recompression" happen entirely on the client-side, and therefore be fair game for hackers to bypass with their own payloads?



https://sneak.berlin/20210425/signal-is-wrecking-your-images...

It's done clientside, and you can't remove it (on iOS) because only official Signal-published builds will receive push notifications of new messages from Signal servers (via APNS).

This doesn't apply to a sender of an exploit, but does apply to normal people who wish to send full res images or patch out the DRM in the Signal app.


they definitely don’t do this, but in principle they could use homomorphic encryption to do the compression server-side with zero knowledge


Not an expert on this so i might be wrong, but pretty sure in homomorphic encryption, you can't run an algorithm that reduces the size of the encrypted payload. Like you could recompress and after decrypting the result is smaller, but that only happens after decrypting.

Besides, its also totally impractical.


nope! you can reduce the size. trivial example is just XOR: Enc(A) xor Enc(B) = Enc(A^B).. 2 bits in, one bit out.

what you can't do is implement variable-size compression like Huffman trees. if you think about implementing Huffman as a circuit, you have a fixed length output - the worst-case length. you can't read the output any more than you can read the input, so you don't know how much padding you can throw away. therefore it's useless.

the same principle applies to running any algorithm that has a dynamic computational complexity. so you can run a Turing machine in FHE, but you won't know when it halts.


It's my understanding that the signal client which is sending the image reads the jpg/png/whatever image file from local storage, recompresses it local client side, and then sends the smaller version.


then that offers no security at all, since an attacker could use a hacked client. unless clients also refuse to receive anything but one, very well-validated, format, so that sending anything funky would be futile.


No, just have the server reject anything at the /SendMessage endpoint over a certain size; presumably the client is resizing / recompressing images to hit a specific target.


That won't help much.

• Compressing to a file size limit is actually difficult/expensive. Tools usually target some good-enough quality level, and then the file size depends on remaining entropy in the image. The limit would need to be conservatively high.

• Exploits aren't necessarily larger than an average image. Adversaries in this case are quite skilled, and may be able to codegolf it if necessary.


Messages support arbitrary files up 100 MB. Images are resized or compressed for user experience on different devices. The server doesn't know what's in a message.


there is no 'server' in a signal client-to-client link except as a directory server for the clients to find each other


This is not true. The server in the Signal protocol is responsible for message storage and delivery, just in a way where it's hard to associate individual message payloads with individual users (except by IP address, of course).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: