fuzzbang

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.

Excellent. You read my directions on how to use TrueCrypt correctly! :)

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.

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.

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.

Actually, @fygrave put together the document (using scigen and a draft from jonathan), so both of them should get credit.

You should clean the data from the user before passing it to the shell. There is a trivial remote command execution vulnerability in the URL ("echo 'GET /;$(cat /etc/passwd)'|nc ..."). I assume there are more.

You have to be more specific than that. These days information security is a huge field. Network security is a misnomer since almost no one works on "network security", which is about protocols not applications / operating systems.

I'd suggest being more specific about what sort of project you're interested in. Will you be doing original research on the size of botnets (you and everyone else in the world); maybe write a tool for something, I'd suggest writing a real webapp security assessment tool. I hate doing web app assessments. Another thing that would be really useful would be collaborative information sharing during a pen test (I've put a lot of thought into this one and could give you more pointers)...

If you want to play it safe, just write another fuzzer. Everyone writes fuzzers. Or you could write some VoIP security tools.

Where is it announced? In particular, how does one find out where / when it is to show up?

The Londoner is at the corner of Sukhumvit 33. Easy to get to. The Bull's Head is down Suk 33/1, very easy to get to by BTS. The Phrom Phong station exit is just in front of the mouth of the soi.

I don't know where the Langsuang Starbucks is, never been there.

The Londoner is larger and doesn't get as packed as quickly (avoiding peak times, of course). Bull's head is a superior pub no doubt, but is not great for a largish meeting.

At any rate, anywhere will do. When is this scheduled for? I'm figuring on heading to the islands later this week.

The Londoner brewpub on suk soi 33. Brewed beer > brewed coffee.