[117114] in Cypherpunks

home help back first fref pref prev next nref lref last post

Re: Project: Hardening Crypto Against Big Brother's "BlackBag"

daemon@ATHENA.MIT.EDU (Sunder)
Thu Aug 26 17:27:08 1999

Message-ID: <37C5AE0F.E53122C4@brainlink.com>
Date: Thu, 26 Aug 1999 17:13:51 -0400
From: Sunder <sunder@brainlink.com>
MIME-Version: 1.0
To: Sean Roach <roach_s@mail.intplsrv.net>
CC: cypherpunks@Algebra.COM
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: Sunder <sunder@brainlink.com>



Sean Roach wrote:
> 

> This may become less of a problem if we ever go to optical chips/busses.

That's a bit far off, but ok.
 

> I don't see how the mercury switches would be a good thing if it is a
> portable.  Better a combination on the case that will set off the failsafes
> if the wrong combination is entered more than twice.  With a spare
> combination which will apparently open it up but only allow access to dummy
> files.

When you're asleep, the cryptobook isn't likely to move.  You turn on the dead
man switch which arms if it's picked up by someone else.  If you're in a
moving car/train/whatever, this wouldn't be wise.  If there's an earthquake,
you'd likely wake up before it went off.  So it's a good thing against
midnight sneaks.
 
> Better.  Use thermite.  Since its only almuminum powder and rust, it
> shouldn't look like more than a large mass of metal, (of which the case has
> a lot of anyway.)

It takes a lot energy to ignite it in the 1st place, you still need a fuse.
 
> Flash memory is no good for holding the OS.  If it can be updated through
> software, you might have just opened youself back up to backdooring.
> Better to use EEPROMS with the erase pin passed through a hardware switch
> so that you actually have to manually flip it to update your OS.

You can disable flashing.  In the worst case you open it and cut the leads to
the chip that allow flashing.
 
> If you are going to have the system maintain an encrypted filesystem
> anyway, you might as well use a hardware solution to encrypt/decrypt.  Just
> like using a video accelerator to free up the CPU for more important tasks,
> have a crypto accelerator built in to your disk controller.  Someone
> mentioned a chip that handles DES, stating that you could use several to
> manage 3DES.  I suspect you would want a chip built around the most secure
> algorythim in use.  Also, you wouldn't need to retain backward
> compatibility on fixed disks, so you could keep that at least at the
> cutting edge.

Building software's easier.  Building hardware isn't.  But it's a good idea
still.
 
> Also, if you can manage it, the non-executables that you swap around, like
> text files, should be fully human-readable.  Something like HTML, but with
> better control.  (Perhaps a coordinate system for placing of elements like
> pictures of underlines.)  This way, you can visually inspect the word
> processor documents without having to worry about if someone hid a command
> in there.  This will, however, make your word processor documents much
> larger for the same output.

Well, you could/should compress them before you encrypt them anyway to get rid
of redundancy...

-- 
---------------------------- Kaos Keraunos Kybernetos -------------------- 
 + ^ +  Sunder              "The real aim of current policy is to     /|\ 
  \|/   sunder@brainlink.com ensure the continued effectiveness of   /\|/\ 
<--*--> -------------------- OF US information warfare assets against\/|\/ 
  /|\   You're on the air.   individuals,businesses and governments   \|/ 
 + v +  Say 'Hi' to Echelon  in Europe and elsewhere" -- Ross Anderson 
---------------------------- http://www.sunder.net -----------------------
"The day that Microsoft makes a product that doesn't suck is the same day
they start making vacuum cleaners."


home help back first fref pref prev next nref lref last post