1993-06-17 - Re: Weak steganography

Header Data

From: bear@eagle.fsl.noaa.gov (Bear Giles)
To: cypherpunks@toad.com
Message Hash: 10aef46ae232cb8045b99fdea384fb8b1cb15d8223098a6521a8b65531341fc6
Message ID: <9306171924.AA13544@eagle.fsl.noaa.gov>
Reply To: N/A
UTC Datetime: 1993-06-17 19:27:59 UTC
Raw Date: Thu, 17 Jun 93 12:27:59 PDT

Raw message

From: bear@eagle.fsl.noaa.gov (Bear Giles)
Date: Thu, 17 Jun 93 12:27:59 PDT
To: cypherpunks@toad.com
Subject: Re:  Weak steganography
Message-ID: <9306171924.AA13544@eagle.fsl.noaa.gov>
MIME-Version: 1.0
Content-Type: text/plain


Eric Hollander writes:
>Another problem is that encrypted files look different from executable
>files.  Encrypted files have a uniform histogram (that is, all 256 different
>possible byte values are equally frequent), but exe files do not.  The
>appending of an encrypted file to an executable file will be very obvious.

So write an encryption routine that wastes bandwidth but outputs executable
code.  You could even encapsulate it within procedures which randomly call
one another, to make it look more like real code.  (Your encrypted data would
be limited to shuffling data between registers and operations within registers,
e.g.:

  mov ax, bx
  add ax, cx
  mov bx, dx
  or  ax, bx

It's not a crime to write bad assembler code... yet.

A nice piece of misdirection would be a homebrew compiler for some
really bizarre language.  A compiler which produces output remarkably
like the output of your encryption program.

If someone asks why you are only using a small subset of the instruction
set, you shrug and claim that optimized code generation is on your "to-do"
list.

Bear Giles





Thread