If the disk is encrypted how can they match file hashes? Do they encrypt known CP files with the FileVault key and then compare? If so, isn't that enough to convict him?
> The Forensic examination also disclosed that Doe had downloaded thousands of files known by their “hash” values to be child pornography.[3] The files, however, were not on the Mac Pro, but instead had been stored on the encrypted external hard drives. Accordingly, the files themselves could not be accessed.
If he's downloading them or storing them by some content-addressable system (torrents, something rsync-like that generates hashes before syncing them, etc.), I can easily believe that there's forensic evidence on the internal hard drive that the files were copied, including the hash of the plaintext, but the files themselves aren't present in plaintext.
This is clearly enough evidence to convict the guy, so I imagine they're holding him for some political reason (like generating jurisprudence for violating the 5th amendment in the future).
Isn't the point of encryption that it doesn't create a reliable hash - that 2 identical files will appear different while encrypted, as part of the larger encrypted drive?
Or are encrypted-hash collisions possible when small files are encrypted individually?
Secondly, when you have two files that are exactly the same and encrypt both with the same key, method and parameters then both will have the same hash. ( Though I could imagine Apple doing stuff with padding, and other parameters to make this not happen)
"Investigators said content stored on the encrypted hard drive matched file hashes for known child pornography content."
I read it like this: They figured out that the disk had some incriminating files, as I described in another comment of this thread. To make this work hashes are of no use, they need the original files. For various reasons they might not want to admit that they are in possession of the original files, hence the cryptic and vague phrasing.
I'm sure law enforcement has lists with hashes of incriminating files, but I'm not sure if they are allowed to keep the original files. Even if they are, maybe they just want to avoid public discussion about it.
The claim is bogus.
You do realize that MD5, SHA-1, and SHA-256 are all hashing algorithms? I highly doubt you meant a cipher built from a hash function (easy to do with Feistel net, though nobody does that), especially that IPsec doesn't define any such thing, from what I remember.
Given that you apparently don't understand how encryption and hashing work and relate to each other, you're not in a position to question the technical aspects of the story.
Agents from the Department of Homeland Security then applied
for a federal search warrant to examine the seized devices.
Doe voluntarily provided the password for the Apple iPhone 5S,
but refused to provide the passwords to decrypt the Apple Mac Pro
computer or the external hard drives. Despite Doe’s refusal,
forensic analysts discovered the password to decrypt the Mac Pro
Computer, but could not decrypt the external hard drives.
Forensic examination of the
Mac Pro revealed an image of a pubescent girl in a sexually
provocative position and logs showing that the Mac Pro had
been used to visit sites with titles common in child
exploitation, such as "toddler_cp," "lolicam," "tor-childporn," and “pthc.”
The Forensic examination also disclosed that Doe had downloaded thousands
of files known by their “hash” values to be child pornography.
The files, however, were not on the Mac Pro, but instead had been
stored on the encrypted external hard drives. Accordingly,
the files themselves could not be accessed.
This shouldn't work because if they had the key (which should be encrypted with the password) then they could also just decrypt the rest.
Somebody on IRC said that maybe the encrypted filesystem saves hashes of the files unencrypted, but not sure if Apple's FileVault does this.
Edit: So two people have downvoted me without explanation. Is what I'm saying wrong?
Sadly, that is the new normal for HN (and, I'll be downvoted for saying something like this)
On a similar note, I wonder if this will spur interest in a kind of file-doping program to confuse hashes of drive contents. A few pixels won't make a difference if you're planning on just viewing some images.
You might have to do more than change a few pixels here and a unicode character or meta tag there. I even suspect things like color grading and, say, something like batching multiple images or text files together into one file, could be accounted for.
Not to mention, such a doping program would preferably alter files in an imperceptible (aka, less mutated) fashion.
I am a bit of an audiophile with my music and go to great lengths to rip high-quality, lossless, perfectly-encoded tracks for the sake of historical preservation. I imagine some pedophiles feel the same way about their data and the thought of tampering with the data's original state is abhorrent.
Even a colorshift or one or two changed pixels might make it worthless in their eyes, much like a bad rip with barely perceptible clicks or an altered noise floor is worthless to me.
They usually aren't using SHA (maybe they are in this specific case).
"It works by converting the image to black and white, re-sizing it, breaking it into a grid, and looking at intensity gradients or edges."
Pretty cool piece of technology. Seems like it covers the obvious bases. I imagine it also ignores meta tags as part of the hashing process, and operates directly on the pixel information.
Perhaps one way to circumvent detection without making perceptual modifications (which would have to be somewhat significant to thwart the above method) could be a program that losslessly converts all of your images' pixel data to a generated file type only understandable by a program with a specific key in memory, which either directly displays the image or creates temporary files that could be used by a regular image viewer? The files could possibly be signed by more than one party for extra protection. I know it sounds just like encryption but I'm thinking of something a little different. Sort of a singular encrypted file that can be securely transferred to any file system.
Sounds like a fun and challenging project but I'd hate for it to be so successful that it leads to child pornographers getting off the hook.
"In December 2016, Facebook, Twitter, Google and Microsoft announced plans to use PhotoDNA to tackle extremist content such as terrorist recruitment videos or violent terrorist imagery."
Dear lord, that is a stupendously slippery slope.
This is an attack, which contemporary block based FDE doesn't really protect you well from. Bitlocker, FileFault, TrueCrypt, VeraCrypt basically operate on one disk block at at time and this means they cannot hide data patterns well. Or as Thomas Ptacek put it in his article "You Don't Want XTS" [1]
>It’s ECB-like. It can’t do a perfect job of providing privacy.
This is also why Thomas Ptacek and others are advocating that FDE is not a complete replacement for file based encryption.
> But that’s the big problem: sector-level encryption sucks. It’s messy, provides fewer security guarantees than conventional message encryption, and makes tradeoffs tailored to the challenges of encrypting disk sectors.
> Sector-level crypto is last-resort crypto.[1]
The Wikipedia article about ECB[2] (which is not used in current FDE) has a dramatic example where the image of the Linux penguin is clearly recognizable in the ciphertext.
[1] https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
[2] https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
1. I didn't claim XTS-mode AES is vulnerable to known-plaintext attacks.
2. I don't believe the investigators claim to have pulled off a known-plaintext attack. What is your source for this?
> Bitlocker, FileFault, TrueCrypt, VeraCrypt basically operate on one disk block at at time and this means they cannot hide data patterns well.
This is wrong, but you claimed it. In the context of this thread (matching files on an encrypted disk with known unencrypted files), that's a known-plaintext attack.
Maybe you weren't aware you were making this claim, but you did.