Spoilation, escrows, courts, pigs.

Trei, Peter ptrei at rsasecurity.com
Wed Aug 1 07:21:40 PDT 2001



> From: 	Black Unicorn[SMTP:unicorn at 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















More information about the cypherpunks-legacy mailing list