I doubt very much that the police had access to the devices before the murder - because if they did then they would surely have prevented the murder and it would be grossly irresponsible of them not to prevent the murder if it were at all possible.
I’m suggesting that, after the murder, the police seized the devices, and gained access to one or both of the devices (using one of the 4 techniques listed above) and then applied forensics to the devices e.g. in this case finding a recently deleted photo file still recoverable on the phone’s disk.
Just think for a moment about the process of taking a photo. Think how many copies of the photo exist in the phone before you even send it securely. It really doesn’t matter (in this context) whether you send it securely if there are copies of the photo littered all over the phone.
Based on the information in this topic I don’t even know whether the phone was Google or Apple - but I can imagine in the Apple world that Apple could helpfully back the photo up to the Apple Cloud as soon as you take the photo, before you even get to send the photo securely. In that scenario, it doesn’t even matter if you robustly, properly delete the photo from your phone. A copy may still exist in the Apple Cloud, where the Greek police can obtain it via Apple. (I’m not suggesting that that did happen in this particular case, only that it is plausible in the general case.)
Yes. That would be my assumption.
Journalists may be trusted but they are not always good with technological details. They sometimes garble the story. In addition, it is in the interests of the police not to be explicit about their tools and methods, since that may allow better technology to counter their tools and methods. So the combination of intentionally vague police and journalists with limited technological knowledge leads to inaccurate and confusing reporting.
And of course the photo being at the “end” means it was outside the end-to-end loop.
Counting bytes. Does encryption change file size or just scramble it? If the encrypted photo is 974,342 bytes and it matches the unsent photo. Of all the other photos on her phone (deleted or undeleted), aha, that’s the “sent” photo.
There is a very old command called “shred” which effectively removes the files from the filesystems (it has a manual (man shred)). But of course this is not available on Android and iOS (I bet).
One term related to changing the size would be “padding”. Different encryption algorithms have different methods of padding, so it would depend on the algorithm. Whole disk encryption does not need to pad a file like you’re describing, since the entire drive is unreadable, but the encryption that Tor uses, for example, will do some padding when sending an HTTP request, to help protect against static analysis, where an attacker might try to match requests coming into and going out of the Tor network based on number of bytes, exactly as you are describing.
Do not trust shred in today’s modern systems. If you look, even the man pages lists caveats, main ones being journaling file systems (like ext), flash memory (non-harddisk memory, so anything in phones) and if systems make automatic backups to cloud. The main protection to data is that you have an encrypted drive so that if it is locked, all files (deleted or not) are unusable (caveat is of course if there is weak login for decryption). Even overwriting a flash or solid memory type device (memory chips) can skip corners due to how the memory handles itself (it helps, but if it wasn’t encrypted to-begin-with, you can’t be sure). There are good up to date sites that go step by step on what to do with modern memory (note: a hammer or drill may be a valid option, fire too as irwine suggested) but shred hasn’t been secure for decades now.
This is a complex question and the answer is definitely “it depends”, since no specific encryption algorithm or protocol is mentioned.
The short answer would be: Yes, the file size changes. The file generally gets bigger during encrypted transmission.
So it is not possible to do an exact match between file length in order to assert that a file on disk of length N that was seen to be transmitted as N bytes therefore it is overwhelmingly likely that that file is the one that was transmitted.
In other words
No.
However just from the sheer size of the transferred file, it will generally be plausible to assert that the file sent over Signal was not a text file and not just a text message.
Some of the reasons that size changes during secure transmission:
Establishment of a secure connection involves handshake / negotiation in order to get the sender and receiver ready to talk to each other. That means that there is a more or less fixed overhead at the beginning (regardless of the size of the file).
If doing both compression and encryption, it is essential to compress before encryption. Hence some encryption algorithms will offer optional compression as an added bonus. This in a small way may offset some of the overheads of secure transmission. (However, for example, a JPEG image is already compressed and therefore won’t compress much.)
Some encryption algorithms require fixed size blocks to work on. Hence the payload may get padded up to the next multiple of the block size.
Protocols may have fixed overhead on each packet. Just as both IP and TCP themselves do, so does, for example, TLS. So by definition you always transmit a small amount more than the underlying payload data.
If a protocol offers integrity (i.e. the detection of packets that are altered in transit) then this will typically involve transmitting some kind of extra value (a MAC/HMAC or a MIC, before or after encryption depending on protocol) that allows the receiver to verify that good data is being received i.e. a souped-up checksum.
This is true - for all the reasons that you list - but you still may be better off using shred than not using shred.
Some solid state storage may offer genuine secure erase. However there is a fundamental problem that the secure erase operation is opaque i.e. there is blackbox code running inside the storage (i.e. the firmware of the storage device itself) and the “secure erase” could be a no-operation (pure theatre) or completely functional, or anything in between, and you have no way of knowing what is the case.
Or that the encryption passphrase is “extracted” out of you.
Its secure, but not as you think. You have to trust the Devices the Apps and the AI on your and the Senders device. And if They share or Store Pictures with others without signal on some social chats or devices its highly liked to got public.
If you have to be private. Meet each other without Smartphones. And use pen and paper.
Even Brains and memories are got digitalize in our present.
Signal is like whatsapp - just with some security for the masses. However the thread is about a trusted environment in the past leaked by third archived in the future.
Like you all feel safe and your family chat got synced with Bytechat, Meta, Amazon… just by your Phones A.I. Your Routers A.I. Your Smartphones A.I. - or your House vacuum Cleaner.
Its so sad. So do not trust that Phones only use paper or low level Linux and self hosted and encrypted offline LAN Service Linux Message Boxes, with less and more less lines of code. Or Rust ;D
I would think that the “small country” has its own policy with services like Signal. Doesn’t the EU have it’s own policy that covers all EU members? California has it’s own grip on privacy policies too.
May 12, 2025 — EU member states are divided. Spain wants to ban encryption entirely, leaked documents show. Sweden has advocated for a proposal that would… (click the link above)
Any way, if a high ranking politician with a finger close to the nuclear button, can share Top Secret stuff TWICE, what is there that says Signal is end to end?
What ever, privacy is being ripped off every day - one way or the other - if average users want privacy these days, lick a stamp.
~s
If you are not being targeted specifically, it is pretty solid. It requires so much more effort to surveil all snail mail content as compared with surveilling all internet traffic.
Also, while your snail mail will still leak metadata, a ban on encryption may not extend as far as snail mail. So you could encrypt your snail mail content.
scan | tesseract | decrypt
metaphorically speaking.
If you don’t mind occasional lost “packets” then your snail mail metadata can even exclude the sender, which is slightly better than internet traffic.
