> iMessage has native support for GIF images, the typically small and low quality animated images popular in meme culture. You can send and receive GIFs in iMessage chats and they show up in the chat window. Apple wanted to make those GIFs loop endlessly rather than only play once,
Any chat or message software you want to be REALLY secure should not have support for rich media of any type. I am even suspicious and skeptical that Signal supports embedding animated images.
I can name exploits of this type on desktop PC operating systems going back probably 22-23 years...
I do realize that lack of rich media inline in messages is a non starter for most non-technical consumer end users.
Signal lets you embed animated images but they still won't let you send native resolution images from your phone to someone else. Signal drastically recompresses any image sent. The only end to end encrypted software I know of that allows that is iMessage.
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?
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.
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.
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.
• 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.
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).
Any chat or message software you want to be REALLY secure should not have support for rich media of any type. I am even suspicious and skeptical that Signal supports embedding animated images.
I can name exploits of this type on desktop PC operating systems going back probably 22-23 years...
I do realize that lack of rich media inline in messages is a non starter for most non-technical consumer end users.