From: Black Unicorn[SMTP:unicorn@schloss.li]

I also made some speculative suggestions about what encrypting such data might look like in a test case extending the facts to be a bit more edgy just to see where the limits were. Such a test case (of which there are none to my knowledge) would easily present a close issue to argue if a savvy prosecutor were around. I'm not sure anyone could tell how it would come out. Consider it a cautionary note for cypherpunks designing evidence destroying (concealing, whatever) systems.

BU: You may be a lawyer, but I'm a cryptographic software engineer. Cleansing disks and memory of keys and plaintext isn't done to prevent some hypothetical court from looking at evidence; there are good, legally unremarkable reasons to do so, which are regarded as good hygiene and 'best practice' in the industry. You've seen the posts on the 'sircam' virus, haven't you? All kinds of private documents flying around the world due to some asshole who gets egoboo out of smashing things. Keeping your documents encrypted helps protect against this kind of illegal surveillance. Backing them up on other computers (encrypted or otherwise) prevents them from being lost to a destructive virus. This is often easier than making copies on removable media. Running wipe programs such as BCwipe is also best practice - I've seen attacks which were based on searching swap files, end-of-file slack space, and unused blocks for 'interesting' data - whether keys (which can be recognized by their low redundancy) or passphrases (look for a printable string on it's own among a sea of binary data as the first cut). Did you know that Windows NT includes a switch to zeroize the swap file on system shutdown? Does Microsoft also need the 'cautionary note' you refer to above? (Yes, they did the right thing at least once :-). As one of the more experienced cryptoengineers at my company, I often wind up training new hires in the ways writing sensitive security software differs from ordinary programming. One of the most important lessons I impart is the necessity of zeroizing all sensitive data as soon as it's need has passed. The programmers also need to be very aware of how procedure calls use the stack, how the heap works, and the implications of garbage collection, disk and memory defragmentation. Destroying sensitive data is part of doing the job right, in a professional, 'best practice' manner. Peter Trei RSA Security