4 ms·

Perhaps we need to make a special decrypt program, one that accepts any password and just produces some log files. They can't prove it is not the data (except b

by tiku 3y ago

Perhaps we need to make a special decrypt program, one that accepts any password and just produces some log files. They can't prove it is not the data (except by claiming they planted it)..

coppsilgold 3y ago
> They can't prove it is not the data Encryption is the one-to-one mapping of a set of bytes to a set of bytes. Software + key is the mapping function. When doing cryptographic forensics you don't use the user's software, you use your own. So proving that the user's decryption program is fake is trivial and may not even come up as you wouldn't bother running it. And you can't choose keys in a way that would alter the byte mapping in a way that you can control, the true key will map to the true data, and anything else will map to random bytes.
- frankish 3y ago
  What if I use my own proprietary encryption algorithm? If I don't specify a file extension, then how could they tell what algorithm is used -- it's just a scramble of bytes. In fact, what if encryption one day gets so good we cannot distinguish it from plain English? Kinda like trying to spot LLM generated content.
luxcem 3y ago
Sounds like steganography, it should be possible to encrypt and merge two files, with one key for each file.
93po 3y ago
This is done on projects like VeraCrypt with hidden containers to give you plausible deniability - one password opens the decoy container and another opens the real one. Of course this means a ton of wasted space on the disk, and as soon as you boot the decoy container it starts desytroying hidden container data. And also there's apparently ways to detect hidden containers if this is to be believed: https://ro.uow.edu.au/cgi/viewcontent.cgi?referer=&httpsredir=1&article=1542&context=eispapers1 https://ro.uow.edu.au/cgi/viewcontent.cgi?referer=&httpsredi... Wildly unrealistic but it exists.

by tiku 3y ago

Perhaps we need to make a special decrypt program, one that accepts any password and just produces some log files. They can't prove it is not the data (except by claiming they planted it)..

coppsilgold 3y ago

> They can't prove it is not the data Encryption is the one-to-one mapping of a set of bytes to a set of bytes. Software + key is the mapping function. When doing cryptographic forensics you don't use the user's software, you use your own. So proving that the user's decryption program is fake is trivial and may not even come up as you wouldn't bother running it. And you can't choose keys in a way that would alter the byte mapping in a way that you can control, the true key will map to the true data, and anything else will map to random bytes.

frankish 3y ago
What if I use my own proprietary encryption algorithm? If I don't specify a file extension, then how could they tell what algorithm is used -- it's just a scramble of bytes. In fact, what if encryption one day gets so good we cannot distinguish it from plain English? Kinda like trying to spot LLM generated content.

luxcem 3y ago

Sounds like steganography, it should be possible to encrypt and merge two files, with one key for each file.

93po 3y ago

This is done on projects like VeraCrypt with hidden containers to give you plausible deniability - one password opens the decoy container and another opens the real one. Of course this means a ton of wasted space on the disk, and as soon as you boot the decoy container it starts desytroying hidden container data. And also there's apparently ways to detect hidden containers if this is to be believed: https://ro.uow.edu.au/cgi/viewcontent.cgi?referer=&httpsredir=1&article=1542&context=eispapers1 https://ro.uow.edu.au/cgi/viewcontent.cgi?referer=&httpsredi... Wildly unrealistic but it exists.