6 ms·

How do hidden volumes, as for example TrueCrypt provides them, play into this? If the defendant doesn't give them up voluntarily the prosecution will have a har

How do hidden volumes, as for example TrueCrypt provides them, play into this? If the defendant doesn't give them up voluntarily the prosecution will have a hard time proving they exist, no? Also, if they do find evidence for their existence - does the defendant then have to give them up?

dalore 13y ago
If they don't have to decrypt known encrypted contents why would they have to give up unknown encrypted contents?
fuzzbang 13y ago
It is not that difficult to prove that a hidden volume exists. The TrueCrypt implementation of hidden volumes means that the "hidden" partition is all allocated at the end of the visible partition. If you have a 20G TC volume with a 4G hidden volume, the file system in the non-hidden volume will never allocate a block beyond 16G. This shows up as very anomalous file system layouts at the block level. Simple visualization of the block allocations will show a clear delineation where the hidden partition starts. The TC implementation of hidden volumes is definitely not robust as plausible deniablility. The police forensics investigators know to look for this already. It is in their recommended best practices for how to handle TrueCrypt volumes. The safest way to use a TrueCrypt hidden volume is: * Create the largest regular volume that you can. * Create the smallest hidden volume that you can. * Never mount the hidden volume as "protected" The idea is that your sparsely populated cover volume won't create enough block allocations to have an obvious "end", and additionally, that those blocks will have a low likelihood of being allocated inside your hidden volume and overwriting your secret data.
- simias 13y ago
  I think the point of TrueCrypt is simply "plausible deniability". They can suspect with a very high degree of confidence that there's an hidden volume, but how do they prove it?
  - fuzzbang 13y ago
    They can prove it sufficiently to force you to hand over your password. File systems have a particular behaviour, they allocate blocks in certain ways. Most notably, they use all of the space available to them equally (or, pseudorandomly anyway). If a file system never allocates any data in the last N bytes, where N is a very large number, that is indication that the file system is treating the volume as Size-N. Since this behaviour is the signature of a hidden volume in a TrueCrypt container, that is "proof". It will be sufficient proof for a court of law. Essentially you are arguing that the file system implementation exhibited implausible behavior (it allocated only from the first N% of bytes), and that TrueCrypt exhibited implausible behavior ("ok, normally that would mean a hidden volume, but not in this case!"). All of which is to say, that TrueCrypt's implementation of Hidden volumes (as typically used by end users) is not actually plausibly deniable.
    - nknighthb 13y ago
      > they use all of the space available to them equally (or, pseudorandomly anyway) This is simply false for many (if not most) filesystems, which preferentially write to blocks near the beginning of the disk. For spinning disks, random distribution of blocks would kill performance.
      - fuzzbang 13y ago
        No, it is not false. The important thing with a spinning disk is locality of reference. You want the blocks which store the file content to be as close together as possible, to minimize the head seek times. This means you want as long a chain of contiguous blocks as possible. This does not mean that you want all those blocks to be at the beginning of the disk. In fact, the exact opposite. You want to start that chain at a random location so you are more likely to have a large number of contiguous unallocated blocks. See the implementation of HFS+ Extents, or Ext4, or UFS for examples of how this works.
        nknighthb 13y ago
        A) You have forgotten basic physics. The beginning of the disk is faster. Locality is desirable but is not and has never been the only thing that matters. B) You have just named three uncommon filesystems that few people will ever use in the first place, much less with TrueCrypt.
- biff 13y ago
  That's how it does hidden volumes huh? I always thought it was something sneakier, like flag a handful of files that exist in the regular volume for it to build its hidden volume out of.
- venomsnake 13y ago
  Well ... a normal PC can have up to 10-12 TB of storage these days . It is more than normal for 1 or 2 to be left empty. You just create the hidden volume there.
  - fuzzbang 13y ago
    Excellent. You read my directions on how to use TrueCrypt correctly! :)
- hackinthebochs 13y ago
  I'm pretty sure this isn't true. You cannot prove the hidden volume exists. In fact hidden volumes are completely useless without plausible deniability. The file system of the outer volume will happily overwrite your hidden volume if you tell it to. The point is that you know its there so you intentionally don't write more than 16G on your 20G volume. But the "unused" space looks just like random data so you can't prove there is anything meaningful there.
  - Guvante 13y ago
    Assuming you don't have it protected, you need to be more cautious than that, as the file system is not simply a long stream of bytes.
    - hackinthebochs 13y ago
      Very true, my numbers were just an illustrative example given the context set up by the comment I replied to.
      - fuzzbang 13y ago
        Which you apparently didn't read thoroughly. I clearly state that the secure way to use TrueCrypt is to never mount the hidden volume in protected mode. That will enable the scenario you describe. I even state the reason why you want use it the way I suggest is to minimize the amount of hidden data that is overwritten.
300bps 13y ago
This would not be the best argument. It's possible to prove you're lying. If on the other hand you merely state you forgot the password, it's impossible to prove you're lying.
lambda 13y ago
Hidden volumes aren't all that great for hiding porn. Generally, porn takes up a large amount of space. Hidden volumes are great for hiding a small amount of data (passwords, launch codes, bank statements, etc) among a large amount; not so great for hiding a large amount of data.

dalore 13y ago

If they don't have to decrypt known encrypted contents why would they have to give up unknown encrypted contents?

fuzzbang 13y ago

It is not that difficult to prove that a hidden volume exists. The TrueCrypt implementation of hidden volumes means that the "hidden" partition is all allocated at the end of the visible partition. If you have a 20G TC volume with a 4G hidden volume, the file system in the non-hidden volume will never allocate a block beyond 16G. This shows up as very anomalous file system layouts at the block level. Simple visualization of the block allocations will show a clear delineation where the hidden partition starts. The TC implementation of hidden volumes is definitely not robust as plausible deniablility. The police forensics investigators know to look for this already. It is in their recommended best practices for how to handle TrueCrypt volumes. The safest way to use a TrueCrypt hidden volume is: * Create the largest regular volume that you can. * Create the smallest hidden volume that you can. * Never mount the hidden volume as "protected" The idea is that your sparsely populated cover volume won't create enough block allocations to have an obvious "end", and additionally, that those blocks will have a low likelihood of being allocated inside your hidden volume and overwriting your secret data.

simias 13y ago
I think the point of TrueCrypt is simply "plausible deniability". They can suspect with a very high degree of confidence that there's an hidden volume, but how do they prove it?
- fuzzbang 13y ago
  They can prove it sufficiently to force you to hand over your password. File systems have a particular behaviour, they allocate blocks in certain ways. Most notably, they use all of the space available to them equally (or, pseudorandomly anyway). If a file system never allocates any data in the last N bytes, where N is a very large number, that is indication that the file system is treating the volume as Size-N. Since this behaviour is the signature of a hidden volume in a TrueCrypt container, that is "proof". It will be sufficient proof for a court of law. Essentially you are arguing that the file system implementation exhibited implausible behavior (it allocated only from the first N% of bytes), and that TrueCrypt exhibited implausible behavior ("ok, normally that would mean a hidden volume, but not in this case!"). All of which is to say, that TrueCrypt's implementation of Hidden volumes (as typically used by end users) is not actually plausibly deniable.
  - nknighthb 13y ago
    > they use all of the space available to them equally (or, pseudorandomly anyway) This is simply false for many (if not most) filesystems, which preferentially write to blocks near the beginning of the disk. For spinning disks, random distribution of blocks would kill performance.
    - fuzzbang 13y ago
      No, it is not false. The important thing with a spinning disk is locality of reference. You want the blocks which store the file content to be as close together as possible, to minimize the head seek times. This means you want as long a chain of contiguous blocks as possible. This does not mean that you want all those blocks to be at the beginning of the disk. In fact, the exact opposite. You want to start that chain at a random location so you are more likely to have a large number of contiguous unallocated blocks. See the implementation of HFS+ Extents, or Ext4, or UFS for examples of how this works.
      - nknighthb 13y ago
        A) You have forgotten basic physics. The beginning of the disk is faster. Locality is desirable but is not and has never been the only thing that matters. B) You have just named three uncommon filesystems that few people will ever use in the first place, much less with TrueCrypt.
biff 13y ago
That's how it does hidden volumes huh? I always thought it was something sneakier, like flag a handful of files that exist in the regular volume for it to build its hidden volume out of.
venomsnake 13y ago
Well ... a normal PC can have up to 10-12 TB of storage these days . It is more than normal for 1 or 2 to be left empty. You just create the hidden volume there.
- fuzzbang 13y ago
  Excellent. You read my directions on how to use TrueCrypt correctly! :)
hackinthebochs 13y ago
I'm pretty sure this isn't true. You cannot prove the hidden volume exists. In fact hidden volumes are completely useless without plausible deniability. The file system of the outer volume will happily overwrite your hidden volume if you tell it to. The point is that you know its there so you intentionally don't write more than 16G on your 20G volume. But the "unused" space looks just like random data so you can't prove there is anything meaningful there.
- Guvante 13y ago
  Assuming you don't have it protected, you need to be more cautious than that, as the file system is not simply a long stream of bytes.
  - hackinthebochs 13y ago
    Very true, my numbers were just an illustrative example given the context set up by the comment I replied to.
    - fuzzbang 13y ago
      Which you apparently didn't read thoroughly. I clearly state that the secure way to use TrueCrypt is to never mount the hidden volume in protected mode. That will enable the scenario you describe. I even state the reason why you want use it the way I suggest is to minimize the amount of hidden data that is overwritten.

300bps 13y ago

This would not be the best argument. It's possible to prove you're lying. If on the other hand you merely state you forgot the password, it's impossible to prove you're lying.

lambda 13y ago

Hidden volumes aren't all that great for hiding porn. Generally, porn takes up a large amount of space. Hidden volumes are great for hiding a small amount of data (passwords, launch codes, bank statements, etc) among a large amount; not so great for hiding a large amount of data.