Specificiation For A Duress File System. Disguised as a Watermark Annotation Management System Maj. Variola (ret), the OsamaSoft Corporation --------------------------------------------------- Background: To deter torture, physically *destroy* your data. If you can't destroy it, you need a *duress* system. It will at least buy some time. Specs for a duress system: Adversary can't know if there's more data You can reveal multiple passphrases to satisfy the Adversary (incl. false data) The former requires stego, otherwise the Adversary could tell that there's more data. The latter requires that your stego'd info doesn't interfere with other stego'd data. Simple Multiple-Use Implementation: Treat the cover media as a block-sized filesystem. The user must specify (and keep track of) the index of the block to embed the payload. To extract data, only a passphrase (not index) is needed if a checksum accompanies data in each occupied block. Multiple blocks can be embedded using the same passphrase, they are all decoded when that passphrase is supplied. (I don't think its possible to store allocation info *in* the file without giving away the presence of more occupied blocks!) Usage: As a watermarking system, anyone can embed any type of watermark in a "block" so long as block occupations are tracked globally. eBay could stego-watermark images in the upper left quadrant, individuals get to use the upper right. Each could use their own watermarking tools. As a collaborative tool, if the annotations are all plaintext this could be like writing comments on the back of a JPG. With the convenience of keeping them with the image. As a duress file system, the watermarks are secret data. They are compressed, encrypted, then embedded in the given block of the cover media. It would be smart to use boring annotations in some blocks so that its not unusual to use the tool with the cover media. (One should also use layers of increasingly sensitive info to give up gradually, as well as plausible fakes.)